《Wireshark网络分析就这么简单》读后感
无论什么工种，坚持不断学习是必要的。工作需要，读几本流量分析的书籍，记一份读书笔记，也算代替读后感。 您可能要结合着看原著或者看过原著才能理解我在记什么。 另外，做了这许多年培训师，还是有一些粉丝很关心我的去向的，您看完就知道了。感谢关心！
前言
我说过，虽然程序员的终点是送外卖，但咱们网工的终点通常不是，而是抓包。
正如书中所说，掌握一个趁手的流量分析工具，就好像学武之人得到了一把称手好剑。而如果你爱上了科来网络分析系统，那一定是因为他不仅仅是一把好剑，他还是一把自带魔法属性的剑。
一道面试题
首先一道面试题这个章节在业界是非常有代表性的。
因为之前的工作经历，我曾经在几种不同的操作系统上做过关于ARP协议的实验研究。因此我认为，在此处引申出兴趣，让各位读者朋友去研究不同操作系统对ARP协议的实现、包括区别，也是一个很不错的锚点。
时间就是金钱，我的朋友。
我的意思是，书中所讲的192.168.1.3/27针对来自192.168.1.129/24的ARP请求做出了响应，单纯的从实验现象来看，也仅仅能够证明在某些操作系统（windows）上会出现这种现象。这个实验如果是使用网络设备，或者换成linux操作系统等等其它场景，又会出现什么情况呢？
是的，这也是我对作者的类似观点表示赞同的原因，我们应当有所心得体会，在网络中，报文才是找出真相的重要依据。
各位读者朋友可以使用其它操作系统来做个测试，看看会不会有不一样的结果，进而引发各位要去复习一下RFC826，加深理解。请在网络上搜索“ping的时候第一个包为什么会丢？”并找到我在cto上的博文了解细节。
报文分析，在我们的日常学习、开发测试、网络或应用故障排除、业务性能问题排查、安全事件梳理等方面，都具有实实在在的重要意义。
一个简单的应用实例
这个实例的分享比较好的体现出了网络流量分析对于IT工程师的实在意义，尤其是网络工程师。
试想，如果读者朋友您是一个刚刚获取了CCIE/HCIE认证的新手网络工程师，并不熟悉所有的网络操作系统，正如书中所说，当您遇到案例中的这个问题时，仅仅查看一下网络配置，甚至是查看路由表，都无法直观的发现问题所在。在这种情况下，或许从网络中的实际流量交互情况来快速定位可能的根因节点是一个不错的选择。
excel文件的保存过程
我有一个观点，天下IT是一家，你家我家不分家（翻译：天下网络一大抄）。
这个看似简单的文件保存过程网络流量分析展示出来的事物处理逻辑，实际上在咱们IT的很多位置都有应用。不多说，比如现在较流行的软件定义存储中的ROW快照、LUN镜像等等产品功能就是采用了类似的名字/ID/逻辑地址替换的思路。
我在《经典网络故障排查》一课中所阐述的观点：无论什么样的业务系统，作为管理员必须知道它“应该”是什么样子的，这样才能在系统出现问题的时候发现不同。这听起来就像是大家来找茬。是的，我们需要知道它“应该”是什么样子的。
如同我们人说出来的话一样，无论内心是怎么做出观点决策包括思考过程，在对方只能去通过我们所讲出来的文字进行理解。同理，甚至更绝对，抛开不同网络操作系统内部的“思考”过程，网络操作系统之间的信息交互完全的依赖着流量交互，是的，完全。
通过网络流量分析，学到、用到。让流量分析工具真正的成为我们日常学习工作中的好帮手。
流量分析工具使用技巧
抓包大小设置、抓取过滤器、显示过滤器、存储过滤器、分析过滤器、自动分析诊断、搜索等等，这些都是科来网络流量分析工具的基本功能。
说起抓包，就是那些书中所说的抓得一手好包的人，其实他们通常都是很666的数据流整理专家。
Patrick的故事
从这一章节可以看出来，作者是一位正经的技术人。谦逊且知道感恩。
我们作为IT技术工程师，也更应该知道人外有人天外有天，我很喜欢这句：“Everybody has his expertise”。
看完这一章节，我翻回去又看了一遍作者介绍。
Wireshark的前世今生
Gerald:“I spent several months doing research and making notes.”
记住这些个名字吧：Ethereal、NIS、AOS、CACE、Riverbed、Steve McCanne、WinPcap、Loris Degioanni。
各位亲爱的读者朋友，铱星计划彻底破产、Google成为最大的网络公司，只有Gerald没有变化，一直在兢兢业业。如果您也是这样的人，那么巧了，我也是。我相信，千千万万的IT从业者中，有一大半甚至更多都是这一的人，任凭风云变幻，我自埋头苦干。
Thank YOU Gerald,and anyother devs in this object.
NFS协议解析
Network File System(NFS) RFC1813
经验丰富的工程师都知道，性能调优是非常非常有技术含量的。
NFS作为较流行的协议，其在业务系统中的重要性不必多说，通常我们学习一个协议或者解决方案会从其发展历史和适用场景了解、内部工作原理解析、交互工作原理解析、不同操作系统的实践操作、业务整体工作情况验收，这么几个方面去形成一个闭环。
根据我的经验，在学通了协议工作原理之后到实践操作验收这个过程，75%以上的同学会遇到各种不同问题，造成这些问题可能是由于规划不当、操作失配、系统进程bug等等吗？不是的，最大的问题在于缺乏实际操练。
这个时候，流量分析工具的介入，通过流量直观的加深对协议工作原理的理解，效果比按部就班甚至对于初学者来说毫无头绪的去做各种无次序的表项检查要好上一百倍。
打个比方（粗鲁了），检查配置 vs 流量分析观察 == 发烧就吃感冒药 vs 中医号脉。
从Wireshark看网络分层
这个章节写得比较经典。作为一个多年的网络技术讲师，我认为这一章节至少很经典的讲出了计算机系统端到端通信模型分层的意义。
同时，我认为这一章节很恰当的引出了流量分析工具在学习和掌握TCP方面的重要意义，是的，但凡稍微学过一点点TCP细节的同志都会有这个体会的（翻译：懂的都懂）。
TCP的连接启蒙
记录一下本章节所阐述清楚的知识点。
UDP比TCP效率
TCP比UDP可靠
TCP序列号的排序作用
序列号和确认序列号的计算办法：
初始序列号暂不关心
下一序列号等于序列号+TCP Payload长度
确认序列号等于收到的序列号+TCP Payload长度，同时也表示之前所有数据已收到，也称为合并确认
如果中间有丢失的报文怎么办呢？
1、根据收到消息中的序列号判断哪些数据可能丢失了，计算那些不连续的序列号就知道了；
2、使用选择性确认，即在确认消息中发送的序列号为期望的下一序列号（也就是没收到的，缺失掉的数据序列），表示期待收到的下一序列号，这个消息会提醒对端重传相应的丢失消息；
说明了TCP消息标志位：SYN、FIN、RST的作用；
从实践角度说明了TCP为什么是三次握手，而不是两次或者四次。
无论是三次握手，还是四次断开，都不100%可靠，这里推荐读者朋友们去看看“两军问题”。
TCP窗口
这一章节很经典的讲清楚了TCP的滑动窗口机制、包括窗口大小和MSS之间的关系，需要强调的是，接收窗口大小是由接收方确定并实时通过消息通知窗口大小（其实就是接收缓冲区）变化。
1992年，历史原因造成的窗口大小限制问题得到了解决，使用TCP Window Scale。RFC1323中提到的TCP Window Scale，在科来流量分析工具中是有非常直观的表示的。
作者提到的某些设备无法识别Window Scale这个选项，也是需要关注的重要问题，当然时隔多年，您见到这种设备的概率不大了。如果真的遇到了，从三次握手抓起，来进行流量分析，也是有必要的。
重传的讲究
发送窗口收到接收窗口大小和网络因素影响。
网络拥塞造成丢包、确认消息丢失。
这一章节中写到的无数绝顶聪明的工程师，应该不包括我。
发送方维护一个虚拟的拥塞窗口（从慢启动到拥塞避免），我习惯称它为：在死亡的边缘疯狂试探，继而害怕失去。
RTO 超时重传，即一定时间内未收到确认，认为数据已经丢失，主动重传。
作者所提到的多一道公式就会丢失一半读者的原理，我颇感兴趣，也将在以后的作品中进行实践，以观后效。
关于发生拥塞后临界窗口值这块，我也认为RFC5861更加科学。
RFC5681认为应该是发生拥塞时没被确认的数据量的 1/2，但不能小于2个MSS。比如说发了19个包出去，但只有前3个包收到确认，那么临界窗口值就被设定为后面16个包携带数据量的1/2。
关于TCP快速重传的触发机制，我认为很好的体现出了计算机世界的一切都是现实世界的映射这件事情。所谓亡羊补牢为时未晚，说的就是这个道理。在真正的拥塞发生之前，抓紧把丢掉的包补上，能有效避免更大的性能问题。比如接收缓冲区满。
RFC2582和RFC3782定义的NewReno重传解决方案，相对较好理解，就是通过确认序列号缺啥要啥，补全了发送最后一个序列号。
而RFC2018定义的SACK重传方案就更相对更好用缺稍难理解。
此外，本章节中关于丢包对小文件性能影响较大的结论，很值得我们关注。
延迟确认与Nagle算法
关于这个章节，我想举个稍显恶心的例子。有没有喜欢攒脏衣服的小伙伴，比如你有一双袜子想洗，不想手洗，用洗衣机又觉得浪费，因此攒十双一起洗或许蛮不错。
严重声明，我没有这个习惯。
事实上，延迟确认与Nagle算法这个话题，我们势必要在黑白之间稍作妥协，取个折中方案。即，没有必要就不要管它，真的遇到了能判断出原因，我认为，这对于绝大多数工程师来说，就足够了。
百家争鸣
这里提到的“临界窗口值”，即当拥塞窗口处于临界窗口值以下时采用增速较快的慢启动算法；当拥塞窗口升到“临界窗口值”以上时，则改用增速较慢的拥塞避免算法。这套思路的确是很科学的。
我想说的是，与之思维模型相近的一个网络协议算法：BGP路由惩罚。
让我们记住：Richard Stevens（TCP/IP协议详解，卷一：协议）、RFC2001、Saverio Mascolo（Westwood、Westwood+）、RFC2581、Vegas等等。
个人观点，鉴于社会实践的创造性和多样性，TCP做为至今仍旧占据网络传输主战场的协议，其历史上的算法发展乃至于未来的算法发展，都会持续“百家争鸣”下去。
简单的代价UDP
UDP没有分段这个操作，这也是我在历来的TCP/IP课程中强调的，CCNA培训中所涉及到的传输层分段功能其实目前只有TCP。同样的也包括重传、数据恢复等等，这些都是TCP的能力。
后续根据需要，我会出一些有关HTTP3的作品。因为HTTP3的传输层是UDP。
剖析CIFS协议
作者，您说的大学时候有人在D盘里面放了几部小电影最好指的是《东方不败大战蓝色妖姬》。
如您所说CIFS只能基于TCP，是的，要想跨越遥远的网际网络向老师们请教一二，也只能用TCP。
个人见解，CIFS的这个Create操作，像极了HTTP的POST。
列一下这里引出的比较好的问题：
CIFS的权限继承问题很好玩；
多个用户访问相同文件的冲突问题（某些资源一旦共享就会带来问题，是吧）；
机会锁，虽然是和协同在线文档处理相关的一个机制，但这个知识点多多少少让我想到了VCS（版本控制系统）；
看，通过流量分析，还能看出来不同文件传输工具和协议的区别（windows explorer是单线程的），流量分析的重要性妥妥的；
通过流量分析，能看出通过CIFS在远程或者远程到本地复制和剪切操作的本质是什么；
网络江湖
这一章节中所讲，NFSv4提出的COMPUND CALL理念，像极了我国现在备受广大群众支持的一站式窗口服务。对于在服务器端应用内部发生的事情不得而知，但作者使用“变量”思维这个解释，我认为相对还是很恰当的，我们也可以将其称之为“实例化”。我认为，RPC、HTTP和REST的POST操作，也是这种思路的实践。
关于SMB3这个小节提到的SMB3会话可以由多个TCP会话承载的思维，我认为与多个无连接的IP路由路径可以承载一个TCP会话是有异曲同工之妙的。
书中提到SMB3的“Continuous Availability”特性，我以为属于以协议层为主要参考的冗余功能了，现如今的存储系统冗余，如果一定要说到硬件故障级别冗余，我认为华为的多控制器存储设备结合华为FlashLink技术是非常不错的选择。
DNS小科普
不知道为何，读了这一章节的第一句：“有一些技术，人们即便每天都在使用，也未必能意识到它的存在”。我脑海中冒出的是：哪有什么岁月静好，只是有人在替你负重前行。
稍有感慨罢！2008年5月发生的那件事情，是改变了我活法的。也是从那时起，我不再满脑子只想着赚大钱，出人头地什么的。我的心中就只剩下一个想法：人活着，就好好的做些有意义的事情。我们这代人，生在流金岁月不假，但坚持一条人间正道又谈何容易。到处都是享受着社会红利，却对社会现状破口大骂的同龄人，什么各种不公各种不好的。我也曾经有这种想法，但过了三十岁，回头想想看看，我不禁问了自己几个问题：我从哪里来？我以前做什么？我以后做什么？我要往哪里去？
别人家的私事咱不便多聊，只说眼睛看到的。我身边认识的我们这一代人，大多都是有车有房有存款的，少数人一线城市定居，极少数已经实现了财富自由。只举一例：我们小时候吃的是冰棍，现在吃的是哈根达斯。补充一句，为这个社会做什么样的贡献，才值得享受这么多红利，我认为，每天做个朝九晚六的社畜应该是不够资格的，当然，我只是我真的是在自勉。
停，继续读书。
温故而知新，回顾一下DNS记录吧。
A记录 域名到IP地址
PTR记录 IP地址到域名
SRV记录 域中的DC
CNAME记录 别名
读到有关递归查询和迭代查询的区别这块，在翻了搜索引擎上的几篇文章后，我认为非常有必要分享一下我的心得。
首先我们用一张图来帮助大家看懂DNS服务器之间的架构
根服务器存储着顶级域名服务器的信息，如果你要找www.saiban.com，并且是向根服务器发送了解析请求，那么根服务器会告诉你com的IP地址，你再去找com服务器，com服务器再告诉你saiban的IP地址，以此类推，直至得到最终结果，这就叫迭代查询。但通常情况下，我们日常所使用的终端不会使用迭代查询。傻子都能看得出来，要是所有终端都去找root做DNS解析，别说13台，这个数字加几个零恐怕资源也不够用的。
是的，所以再看下图。
通常我们的终端设置的DNS服务器都是内网DNS或者本地DNS服务器地址，终端发出解析请求，内网DNS以本地记录或者缓存记录做响应，如果没有记录则向上级DNS服务器请求记录，然后将结果返回给终端，这就叫递归。
通常情况下，如果本地DNS服务器在本地缓存中查不到记录，则会去向根服务器发送解析请求，通过上面提到的迭代过程来获取结果，最后由内网DNS服务器将解析结果返回给终端。
引用《士兵突击》中的一句电视剧台词：“很多简单的事情蛮复杂，很多复杂的事情又蛮简单”。DNS亦是这样，它是一个既简单又复杂的全球化系统。我的意思是，所以，在这里，那些缓存啊记录啊之类的其它内容就不写了，毕竟我这是个正经的读书笔记，我只想写写我认为我想写下来的内容，而不是科普文章。
DNS的缺点及可能引发的安全事件。
使用山寨域名钓鱼，这其实不关DNS的事，但DNS却又实实在在的存在于这类安全事件中，个人觉得这其实比较像最近注销的“块勃”公司所经历的；
被黑客控制的DNS服务器实现钓鱼；
被缓存投毒的DNS服务器，其实和上一个很像，只不过黑客仅仅劫持了DNS服务器的缓存；
DNS放大，这是一种基于源地址欺骗的反射型DDOS；
DNS劫持，这个就更狠也更大胆，跟冒充警察一个意思；
一个古老的协议FTP
FTP的发明人，印度工程师Abhay Bhushan，我没有get到为啥要强调是印度工程师，哈。
对于不了解的读者盆友，还是需要知道一下，FTP的控制连接和数据连接，以及它的主动模式和被动模式。
读到这里，我不禁又想分享一下我对协议这个概念的认识。
通常情况下，一般的协议，也可以理解为约定、暗号等等。在互联网时代，我们都知道不同网络操作系统之间的信息交换是通过在网络上交互的消息/报文来实现的。所谓协议，也可以理解为事先约定好的消息理解方式。
上网的学问HTTP
阿兰图灵我知道，Donald Davies和Tim Berners-Lee也知道，但是作者说的大家心中已有合适的人选，我的确不知道，万分抱歉。
噗，好吧，我也在此明文祝福楼主一生平安。
我解过IPSec、SSL、TLS、RSA、DH等等基本原理，但对椭圆曲线（ECC）算法并未深入涉猎过。
说到HTTPS、SSL，理论上讲，在已知服务器/客户端私钥的情况下，是能够将流量进行解密的，但也仅仅是通过一定手段获取私钥。私钥在正常情况下是拿不到的。
无懈可击的Kerberos
windows域环境的身份认证就用到了kerberos。
噗哈哈哈，老板伪造网络打印机然后真的得出去求职了这个好好笑啊。
其实我觉得这个对暗号的文本换成：天王盖地虎，宝塔镇河妖，更加有趣一些，不过无所谓啦，就不是作者主要意图。重要的还是那句：“同志，我可找到你了！”
总体来说，kerberos认证解决的就是如何证明你是你的问题。当然，要加上一句：无懈可击的证明了你是你。
TCP/IP的故事
Emm,RFC2468
关于不再介绍OSI这个观点，我很赞同。
好吧，这一节真的就是在讲故事。
一小时内给你答复
关于这个练功的比喻，我深有同感，作为一个曾经培训过（）名CCIE的资深讲师，我只能深感无奈地说，我唯一能做的就是在讲明白每一个知识点上下足了功夫。我不愿看到我们培训出来的学员出去祸害别人，更不愿看他们找不到合适的工作。
好吧，中肯的说，这一波流量经过NAT设备导致安全策略失效的故障排查，也并不是一般的网络工程师能轻易解决的。
这其实并不难，难的是，当这整套基础架构并不是我们亲手构建也并不是实际运维人员的情况下，一时间并不熟悉客户的环境，仅仅关注C/S两点也是很多工程师的通病。
在这个小节中，我的体会就是，我们很多工程师并不足够熟悉多种协议和业务系统，在这种情况下，清晰的故障排查思路、运用好的工具和及时求助于有经验的技术专家往往是最后的防线了。也欢迎各位读者盆友早早来跟科来合作，嘿哈。
午夜铃声
这，这个造型诡异的建筑，难道是什么什么衩？
还有还有，ghost盘，听起来好像不那么合规的一个时代产物。
当然必须要承认的是，这一波TCP流量分析，还是非常到位的。当然要做到这一点也不容易，工程师需要有足够丰富的经验，对TCP的工作原理清晰理解到位，对TCP/IP分层协作理解到位。
这个故事告诉我们，重启重启重启换机器是最管用的，但这种方式不能适用所有场景，还要考虑到重交付项目的一些制约。
深藏功与名
目测作者这一波甲方爸爸们的舒服待遇展示，应该会让很多工程师感同身受吧。
这个案例所提到的TCP重传对性能影响较大，是需要一个物料去分析讲解一下的。
各位小伙伴记住，SACK是有开关的。其实很多选项和功能都是有开关的，这一点其实取决于各位在学习时千万不要被带偏了，不要被“名师”误导。
说到午睡，目前来讲，我在科来这边也是可以午睡的。
棋逢对手
在冰冷的机房连续工作十多个小时，旁边还站着咆哮的上司。这个我没经历过，但的确有一些学员是这样告诉我的。
偶尔卡一下、不定时的、稍纵即逝的，这的确是让很多专业人员都头疼的问题，非专业就不提了。
一线抗了一个礼拜、二线抗了一个礼拜，最终找到了作者，咳咳，作者大神不用怀疑了。
我在做CCIE培训的时候，也一直跟我的学员说，出去了记得一句话，问题到了你这里就是终点。如果你解决不了，就说是跟（）学的，千万别把师傅我供出来。
事实上，通过科来网络全流量回溯分析系统，全天候的记录网络中所有流量，对出现问题时间点的流量直接进行回溯分析，就不用自己写程序了，嘿哈。
其实很多时候，我们最终定位出来的问题根因，都不是什么大不了的，它可能只是一个简单的设置，但当一个网络操作系统节点囊括在一整套业务系统中时，它带来的往往就是不可估量的损失。如同做人一样，每一台网络操作系统节点在整个业务系统这个团队中，都要各司其职的做好自己该做的事情，否则带来的就会是整个团队的损失。
学无止境
哈哈哈哈哈，接收方不时回复“TCP Window=0”给发送方，呃，我举个正能量的例子，这就好比甲乙相约一起做运动，甲体力不太行，每跑几米就喊着说不行了不行了，就要休息一下，然后再继续。这样的话，最后甲肯定是达到运动效果了，但是乙因为体力比较好，可能就毫无运动痕迹。
当然，我强烈推荐各位读者如果有条件的话，推荐您的老板在业务系统中部署科来网络全流量回溯分析解决方案。这肯定比tshark好用多了。嘿哈。
一个技术男的自白
说实在的，这个标题我看着总觉有点自我悔过的意思，哈。
对于全栈工程师这个话题，我更倾向于赞同作者所说的，我希望各位读者能够把多数经历投入在一门技术上，而后一通百通，这也是我个人真真切切尝到的甜头。
我还记得多年前，健身房的那个健身教练跟我说的，你不用管那么多，也不用请什么教练，你就找固定器械去练，记住了胸肩背腿腹，一星期练五天，每天练一个部位，只要你能坚持下来，什么都会有。
学技术这块，我也是这个观点，您不用纠结到底是什么都学还是专精一门，这意义不大。就记住俩字：坚持！什么都会有。我一直坚信这个故事，那个只会少林长拳的虚竹，加持上70年的内力，就是天下无敌。
就我个人经历这块，我考取的第一个CCIE证书，从学习到考完用了四个月，第二个证两个星期，第三个证一个星期。这就是坚持专精化学习给我带来的真实好处，我每看到一个新的IT，总是能很快的接受它的思想和理念。
作者说得很好，切忌浅尝辄止。
关于办公室政治这个小节，我较同意作者观点。我们用自己的技术帮助所有人，技术人天生就有一种奉献精神。我不反对办公室政治，但如果我认为我的工作环境不能让我专心的做该做的事情，或是这个环境影响了我的个人发展，那么我会立刻马上找好下家并离开它，因为，舍得对天生自带奉献精神的技术人下手的人，（）。
关于创业，我的观点是，如果您是为了赚钱，请不要创业，这个国家还需要很多很多的建设人才，请不要打着技术回报社会的旗号去为自己捞金捞银。正如我前面所说，2008年5月的那件事情，改变了我许多，我们就好好的，做个好人，挺好的，不要满脑子想的是钱，要想奉献和付出，自然能得到相应的回报。不要相信那些鬼鸡汤，什么待到成功时把酒言初心之类，社会规律必须是你先要做到奉献和付出，才能有回报。
关于跳槽的话，我跳槽来到科来是人生第一次跳槽，我在上一家公司做了七年四个月四天，上上家公司也是七八年。所以，这一块我没啥可说的观点。
关于职场社交这个话题，我想说的是，参与营销工作或是销售辅助甚至销售是每个技术人到最后必须要走的路，因此如何磨练自己的性子，如何掌握与人交流沟通，各位读者粉丝盆友自行把握吧。
关于生活，反正你们玩得都够花花的了，我就不多说了，什么单车、徒步、绘画、钓鱼、越野、bulabulabula的，至于我玩哪些，咱们有缘江湖见。
最后
非常感谢您能在百忙之中读完。
