《wireshark网络分析的艺术》是一本由林沛满著作，人民邮电出版社出版的平装图书，本书定价：45.00元，页数：198，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《wireshark网络分析的艺术》精选点评：
●Wireshark 只是优秀的工具，最主要的还是要对基础知识理解透彻，才能在优秀工具的帮助下游刃有余的应用。
●看完“Wireshark网络分析就这么简单”紧接着就看了这本，两本书有一定的衔接。这本同样的写作手法，幽默并贴近实际工作，虽说是本讲技术的书籍，但读起来有种看侦探小说的感觉，带入感十足，不知不觉中就到结尾了。这两本读下来，对协议的细节产生好感，立马下单“TCP/IP详解：卷I 协议”。
●用实战经验来写书，真的让人耳目一新。例子都是身边经常发生的，解决问题的思路非常值得学习。
●篇幅很短，很有趣，可惜自己对tcp/ip了解不深，实际工作也用不到，以后有机会抓包玩玩
●文笔依旧非常好, 不过,让人感觉分析起来好容易啊, 但是到自己真实上手的时候,才发现远没有这么容易啊.
●本来期待讲wireshark怎么使用。但是意外的是作者讲了更多wireshark的分析方法。作者的分析思路是非常值得学习和培养的。
●贴合实际，字字珠玑，处处是梗。人生道理和笑点同在。粗体字的划重点方式有效。转行，已无时间读技术书籍#2020# 有些地方的技术项目，就像一个垃圾堆，大家都在垃圾堆里混吃混喝。
●LSO还是有用的。 跟着林工的思路不自觉地做了一份TCP和UDP的比较，觉得可以让面试官满意哈哈哈。
●当年也是分析过LTE TCP百兆性能问题的，这书读来甚是亲切。书上的这些问题场景其实懂了后就不难的，真正难的是能不能想到问题的点才是解决问题的关键，这时积累就显得尤为重要，否则可能得抓瞎好几天。台上一分钟，台下十年功，努力
●打开了不少思路。
《wireshark网络分析的艺术》读后感(一)：一如既往的好
这本书躺在我的京东收藏栏里已经好久了，发售之后我赶紧买了一本，从序言开始读起，惊异于作者竟然引用了我1年多前对《Wireshark网络分析就这么简单》的书评，挺激动的，也算是我的文字首次上了一本书吧。
书还没有细读，但是能发现依旧沿袭之前理论+实践的方式，这种方式是我喜欢的。先占个坑，以后慢慢补。
《wireshark网络分析的艺术》读后感(二)：基于wireshark而高于wireshark
正如 @红茶三杯 所言，这本书是“基于wireshark而高于wireshark的”。虽然标题说的是Wireshark，每一篇也都用到了Wireshark，但本质上讲的都是比较有深度的网络技术（通过Wireshark来呈现），而且都是实际案例，所以对运维、技术支持、IT、网管等职业比较有价值，对考证爱好者则没有什么用。比较推荐其中的几篇：
1. Linux为什么卡住了
2. 像福尔摩斯一样思考
3. 最经典的网络问题
4. Wireshark的提示
5. 谁动了我的网络
6. 自学的窍门
其中有两三个案例比较难，比如如何估算网络拥塞点，需要老老实实读完前面两篇铺垫。
《wireshark网络分析的艺术》读后感(三)：擅用工具是最好的学习方式
我很少会去问别人问题，我觉得假如可以通过问别人来获取答案的话，那么通过资料（包括源码）以及借助分析工具会得到更好的答案。得来全不费功夫的不叫知识，实践才会出真知。
这本书也是在阐述这个道理。
我比较欣赏像作者这样针对某个细分领域写书的人。国内的技术书籍给人的感觉就是大而全浅而泛东抄抄西摘摘，完全没有自己的独到见解。像作者这样能够在某一特定方向写出自己领悟的真是凤毛麟角。作者对待技术的态度就很值得我们尊重，这也是我买这本书的主要原因。
这本书是通过一个个案例来阐述背后的网络知识，以及针对这些问题现象我们可以怎么样去一步步找到背后的根本原因。网络知识是很庞杂的，先不说熟读RFC，即使能够把《TCP/IP详解》给深入的学习一遍就足以皓首穷经了(也许你天资聪颖过目不忘很快就悟透所有，但相信绝大部分人都如我这般看那本书看的头昏脑胀双目痴呆不知其所以然翻了一遍等于没翻)。所以就我现在的理解力而言，我觉得网络知识学习的最佳切入点就是去解决实际问题，在解决这些问题的过程一步步去探究背后的知识。而且在解决实际问题的过程中，我们也更容易明白在这种场景下为什么会这么设计，其他场景的设计方案是怎么样的，背后到底存在着怎样一个逻辑，有没有更好的实现。在分析问题时，如果有一个强大的分析工具来助你一臂之力，你一定会发现更多，学习更多，而且事半功倍。 wireshark就是这样一个工具，我跟作者有同感。
但是，不能止于此，我们不能简单停留在熟练掌握工具上，我们还需要去明白这些工具的关键点是怎么设计实现的。这也是我觉得这本书存在的一个不足之处。
wireshark，它的本质是抓包 + 过滤，以及更加友好的展示; 在linux(以及unix)上则是tcpdump来抓包(tcpdump自身也包含着一些基本的过滤手段)，tshark来过滤；本质上都是pcap + filter。 如果你分析过网络问题，特别是一些随机出现掌握不了规律的一些网络问题，你一定会有这种感觉：抓包容易，过滤难。所以这里面的关键部分是过滤：设置一个好的过滤条件，把你感兴趣的包筛选出来，然后还可以更进一步做一些逻辑处理，然后你的问题就会一目了然。就像这本书里《打造自己的分析工具》里面做的那样。一个好的包分析工具，好就好在有效的过滤和友好的展示上。
举个实际的例子，之前我们的一些http服务会出现一些RT（response time）随机抖动的问题，一天可能出现几次也可能不出现，可悲的是我们也不知道复现规律。那怎么办，没有办法了，只好tcpdump一直跑着去抓包了，服务器上成百上千个连接，抓出来的东西可想而知，很大，非常大，即使我们设置了很精细的过滤条件，即使我们只去抓取头部。 然后出现RT抖动后，我们再去肉眼去找这一时刻抓出来的包，一个个去看这个时刻附近的包，两眼酸痛，头昏脑胀，呜呼哀哉。 这个时候一个合适的过滤以及友好的展示就体现出来价值了。 于是我就找到了tcprstat这个工具，当然这个工具也存在不足之处：它只能用来在server上去做抓包分析，于是我就对它做了一些改进让它在client侧也可以抓包分析，然后server和client抓取出来的数据再借助gnuplot进行可视化，友好的展示出来，这样子我们就可以判断出RT抖动是发生在client，还是发生在server，还是发生在网络中间节点上了。 然后再去进一步分析即可。
所以，不拘泥于工具，去明白工具背后的原理，然后打造出来你自己的合适的分析工具，才是最重要的。
在讲wireshark这个工具使用的同时，也要去讲清楚它背后的逻辑以及设计要点，这是我给作者的一个建议。
至于本书的最后一篇文章，我看了下书的写作日期是15年底，那个时候google的BBR还没有出来，不谈了。
anyway，这是一本好书，作者是个认真的技术人员。
《wireshark网络分析的艺术》读后感(四)：用wireshark分析网络
这两天看了两本有意思的书，Wireshark网络分析就这么简单、wireshark网络分析的艺术。
之前工作中就常常用到这个软件，好多时候总是感叹这个软件实在太NB了，这本书作者也是个实战派，采用种种案例展示了如何用Wireshark探索网络现象，实在是很迷人。
其实绝大多数网络问题最后找到原因都很简单，但是当一个大型的网络里面发生诡异的情况时，能迅速定位问题点是很不容易的。我又回想起来之前工作时，在一个客户现场遇到的坑。
很久很久以前~~~
咳咳，其实也不是多久，但那个时候我已经工作挺长时间了，虽然没有经过什么系统理论培训，但是靠着大量野路子实践，我觉得也算是见过很多网络万年坑了，我去客户现场从来不怵头，但就是那一次，差点阴沟里翻船~~
我去国内的某家大型券商部署项目，那家券商真是壕啊，从服务器到网络设备都是定制的特别高端的一批货，然后我熟门熟路的安装好Centos7.1，他们的系统管理员按照内部规定，做了安全防护之后，我们从他们的顶层小机房转移到操作办公室，准备部署应用软件。
这家券商的网络大部分已经迁移到SDN上面，办公室的终端机器经过两层跳板，跳到一个云主机的shell上面，然后再远程ssh连接到我们刚刚装好的服务器上，准备大展拳脚~~~~
根据故事的发展，这个时候就出现了诡异的事情，随机过20~40分钟后，我们的ssh连接就会卡一段时间，然后有几率断掉，之前所有工作都是正常的，而且有时候能正常个1小时，但是最后总是会开始卡。
唉，网络卡死，网络时不时断掉，真的是现场网络工程师人生中的一大悲剧，这类问题感觉天天遇见，但是总是没有一个固定的套路去解决它。
我们的终端机经过了两重跳板，然后ssh客户端和服务器之间，还有一个庞大的网络拓扑，跋山涉水十万八千里才能相见，然后就被某个不知名的幽灵生生拆散了，想象他们艰难的会师路径，我不禁打个冷颤。
肯定不能先去怀疑他们的会师历程，我们先去查找最简单的，也是最容易出错的部分，就是服务端的sshd配置
因为安装完系统后，客户的管理员根据他们的安全管理条例，运行了自己开发一个脚本进行了系统加固，很自然的，我们怀疑这个脚本是不是有什么地方配置不对，导致问题
在对服务器配置文件和脚本代码详细检查之后，我失望的判定，人家的脚本没问题
配置没有问题，那就看看是不是ssh终端软件有问题呢
我反复使用ssh登陆不同的服务器，惊奇的发现，凡是登陆我们刚安装好的这批服务器，就会时不时断掉，其它服务器就没有问题； 但是悲剧的是我们的服务器所在的机房，没有其它测试机，所以只能证明ssh终端软件没问题
不到万不得已，我是不想怀疑中间庞大的网络路径的，谁知道是不是什么抽风的防火墙规则呢
我抱着笔记本，跑到楼上服务器的小机房直联看看，发现直联好得很
现在说起来简单，其实跑一趟机房需要审批、内部人员带路一堆手续，累的客户跟我上上下下，验证一次需要1个小时以上，而且重现时间是随机的，这就是一线人员苦逼的地方啊。
看起来一切都导向那个我最不愿意看到的结果，好像是通信中间有个什么诡异的防火墙规则之类的~~，但是这么庞大的网络拓扑，怎么定位问题呢？
到了此时，客户不再纠结于安全管理条例，我们小心翼翼的祭出了·抓包·这个手段
不到万不得已，其实大家都不想抓包的；金融行业的客户群，重视安全问题甚于生命，所以能在生产环境中让你抓包，其实已经是皇恩浩荡了。经过了几十分钟苦苦等待，终于问题又重现了，我们小心翼翼的把抓到的包存到本地，用wireshark打开，像欣赏小电影一样仔仔细细~~~果然有问题，那台服务器的ARP响应包里面，MAC地址竟然会变！奇哉怪哉，我们刚配好这台服务器，怎么就让人ARP欺骗了呢？而且如果是他们的网络里面有ARP病毒，为啥就只找我们的服务器呢？当时已经从早上折腾到下午3点种左右，虽然有了重大发现，但是也有了更大的迷惑
突然我灵光一闪，服务器接了两根网线，一根是管理口为了方便管理，这个一直没有动过，会不会是~~~
我立马报着笔记本和一台小交换机跑上楼去
将服务器和笔记本通过一台小交换机联到一个小局域网络中，再抓包发现了真相
这台定制的服务器是浪潮提供的，而浪潮的管理口有个奇怪的设定，它和服务器上的多个网卡被绑定成一个NIC Teaming，类型为Transmit Load Balancing（TLB）。TLB的特点就是收包工作只由一个网卡负责，发包工作则分摊给所有网卡，但是管理口的默认配置有问题，有时候莫名其妙会共享同一个IP，回应ARP请求的时候把自己的MAC地址发回去，但是系统中管理口是没有配置的，所以这台服务器莫名其妙就自己变成了一台ARP欺骗源。
问题定位了，我们打电话找浪潮的供应商；供应商也非常奇怪，表明是第一次碰到这种问题，可能是由于定制的机器，考虑不周导致的。
然后我们的解决方法就是，将笔记本直联服务器，在笔记本上运行一个DHCP 服务，这样管理口在开机的时候会被分配一个IP地址，我们再通过这个IP地址登陆服务器管理界面，配置一个静态IP，就OK了。
虽然最后是一个简单至极的ARP欺骗问题，但是发生在一个庞大的网络拓扑中，调试手段被限制，发生时间随机，楼上物理距离和安全条例导致你重现一次成本极为高昂，你还能·镇定自若，指挥谈笑间·吗，这是一次一波三折的排障经历啊。
我这么详细的回忆一次折腾的排障经历，是因为我在这本书里发现了作者和我一模一样的苦逼例子，在<wireshark网络分析的艺术>这本书里，大家有兴趣可以自己去翻翻。
其实这两本书真可谓是作者的网络排障手记，因为我也有那么一段跑在一线的日子，读起来格外亲切。这就是一线工程师的日常啊。
曾经，我以为熟读<TCP/IP详解>和<Unix网络编程>就能成为无所不能的网络大拿；曾经，我以为独立实现一个网络协议栈就是开创天地的神邸；后来，我明白了，网络的海洋无穷无尽，虽然规则是死的，但是现实世界实在不可预测，也许下一分钟就会有一个匪夷所思的case来纠缠你，嘲笑你的妄自尊大。
在网络世界迈入SDN之际，我非常惶恐，因为我明白以我的智商，不可能成为什么·专家·了；我想，未来，可能只有在AWS或者Google Cloud浸淫数十年的人，才能小心翼翼的称自己为·真专家·；面对网络知识的变幻莫测，总有一种·生有涯，知无涯·的惶恐；我总是会感叹，网络这个东西实在是太神奇了，真不知道如何形容这份感觉，就是只有·神奇·来形容