《wireshark网络分析艺术》章节试读

《wireshark网络分析的艺术》的笔记-第200页 - 全书

一些摘抄Linux为什么卡住了分析wireshark抓取的所有时，可以用要关注的协议过滤出相关报文，如“ssh”，然后分析某一段报文时，使用如 “frame.number > 21 && frame.number < 25” 进行过滤技能比知识更重要像福尔摩斯一样思考用 Wireshark 排查问题，和侦探破案的思路是一致的。一篇关于WMware的文章灵感不是天生的，她来自长期的训练来点有深度的在wireshark中查看延迟确认包的方法为：“tcp.analysis.ack_rtt > 0.2 and tcp.len == 0“过滤一下，就可以把所有超过 200 毫秒的确认都筛出来了（当然筛出来的不一定全都是延迟 确认，追求精确的话就逐个检查）三次握手小知识把 Seq 和 Ack 的初始值都置成 0，即用“相对值”来代替“真实值”。我们可以在Edit->Preferences->Protocols->TCP 菜单 中勾上 Relative Sequence Numbers 来启用它。定位大多数握手失败问题的方法表达式 1：(tcp.flags.reset == 1) && (tcp.seq == 1) 接下来只需右键选中过滤出的包，再点击 Follow TCP Stream 就可以把失败的全过程显示出来表达式 2：(tcp.flags.syn == 1) && (tcp.analysis.retransmission) 这道表达式可以过滤出重传的握手请求被误解的TCP就像我们不用每天都跟公司算 一次工钱，而是攒到月底结算一样，数据接收方也可以累积一些包才对发送方 Ack 一次。另一个对 TCP 的广泛误解则和 UDP 相关。有不少技术人员认为 TCP 的效率低，因为其传输过程中需要往返时间来确认（Ack）。而 UDP 无需确认，因此能不停地发包，效率就高了。只要窗口足够大，TCP 也可以不受往返时间的约束而源源不断地传数据。这就是为什么无论在局域网还是广域网，TCP 还是最受欢迎的传输层协议。最经典的网络问题Nagle 和延迟确认本身都没有问题，但一起用就会影响性能。计算“在途字节数”在途字节数 = Seq + Len − Ack其中 Seq 和 Len 是来自上一个数据发送方的包，而 Ack 则来自上一个数据 接收方的包。估算网络拥塞点发生拥塞时的在途字节数 即是该时刻的网络拥塞点。明白了这一点，估算拥塞点就可以简化成找出拥塞时 刻的在途字节数了。本篇文章详细的介绍了估算网络拥塞点的方法，估算时可以参考顺便说说LSOLSO（Large Segment Offload）启用 LSO 之后， TCP 层就可以把大于 MSS 的数据块直接传给网卡，让网卡来负责分段工作了Windows 上只需要在网卡的高级属性中找到 Large Send Offload 项就行了技术与工龄工龄的确可以累积经验， 但不一定能提高多少技能。 就像你花足够多的时间也可以把相对论背诵下来， 但物理水平不会因此提高多少。一个面试建议问题描述要引人入胜抓住互动的机会拒绝浮夸分享技术如果他第一次见面就能从你这里 学到有价值的知识，自然会希望以后能跟你一起工作。即使该知识对他没 什么实际价值，能跟一个有钻研精神和分享精神的人合作也是令人愉悦的这就是坚持写技术博客的价值之一，能用 自己的语言表达出来才算真正理解并且记住了寻找HttpDNSDNS 支持 GSLB（Global Server Load Balance，全局负载均衡），能根据 DNS 请求所包含的源地址返回最佳结果，从而匹配同地区、同运营商的IP，使用户体验到最好的性能。两个项目当你不知道某个特征所对应的 tshark 命令是什么的时候， 可以尝试从 Wireshark 中把它找出来，然后右键点击该特征，选择“Prepare a filter Selected”， 就可以在过滤栏生成表达式了。平时写过滤条件时，如果不知道怎么写，也可以运用这个技巧一些感悟看完“Wireshark网络分析就这么简单”紧接着就看了这本，两本书有一定的衔接。这本同样的写作手法，幽默并贴近实际工作，虽说是本讲技术的书籍，但读起来有种看侦探小说的感觉，带入感十足，不知不觉中就到结尾了。这两本读下来，对协议的细节产生好感，立马下单“TCP/IP详解：卷I 协议”。