路由表启示——我的新伙伴wireshark

这几天学了学wireshark,就用几到了几个语法,不着急学命令,先学抓包的思想,最近看得书《wireshark网络分析就这么简单》,因为对路由表新的理解从而爱上了wireshark,所以这篇标题就给了路由表。

目录

    • 语法
    • 路由引发的好玩的东西
    • 对MSS新的理解
    • seq递增规则
    • TCP WIindows Scale
    • RTO
    • 对TCP的新理解
      • 快速重传的新理解
      • nagle新理解
    • 排错指南

语法

1.ip.addr eq 127.0.0.1 找源/目的ip是127.0.0.1的包
2.tcp.port找专门的端口号
3.arp icmp http 查找协议

路由引发的好玩的东西

添加一个路由信息,-host表示这个IP是一台主机。dev后面跟着是那块网卡

route add -host 192.168.8.130 dev wlp1s0

当我们ping的时候抓包会发现,最上面这条很明显是绕过了默认的网关,直接广播找目的地址。
路由表启示——我的新伙伴wireshark_第1张图片
这个小例子就引出了一个好玩的事情,大家都知道arp是局域网协议,毕竟不能广播arp消息,不然肯定会广播风暴啊。但如果配置一条假的路由,他就会觉得我们是在一个局域网中从而不走默认的网关了,从而用的是arp协议了。不走默认网关会遇到什么事情呢?两台电脑分别在两个网段,但这两段网络都是公司内网,却发现两个电脑ping不通,两台电脑干别的、ping别的电脑都正常,就是他俩不能ping通很有可能就是发出ping命令的那台主机有一个错误的路由表,让他以为是同一个子网了,而没有走默认的网关通信,我觉得日后解决这个问题是一个可以加薪的排查方案哈哈哈哈。

我们来模拟一下吧,添加一个假的主机名字

sudo route add -host 192.168.7.24 dev enp3s0f3u3
ping 192.168.7.24

过滤设置arp,不用wireshark抓包,怎么能真正理解这条小小ping背后的操作呢~这ARP都发了这么多也得不到一个回应,真是太可怜了
路由表启示——我的新伙伴wireshark_第2张图片
我们在试试没有假路由去ping一个地址的情况,发现并没有arp协议的参与,也就说直接去默认网关ping去了,证明了和我们想的一样。
在这里插入图片描述

对MSS新的理解

我们都知道握手会传win接收窗口大小,我们也知道TCP为了效率不会发送一个包就停下来等一个ACK(如果win太小是等的),但我却没有思考过一个问题,如果TCP可以发送多个包出去,那么怎么判断啊?随着看这本书我思考了这个问题并且解决了,就看这个MSS段,如果win是2920,,一个MSS是1460字节,也就是可以发两个包,TCP头部和IP头部不包含在上面。这也说明如果
win的窗口大小是不包含tcp和ip头部的字节大小(写这篇博客意识到的问题)
路由表启示——我的新伙伴wireshark_第3张图片

mss确定一个包可以是多大,win窗口大小是负责一次可以传多少包的,win=16000,假设mss是1000字节,也就是一次可以传16个包,相当于上图一次性发送16个1000seq给目的地。

seq递增规则

下一个seq = 当前seq+ len,ack = 对端发来的包 + len。
举个例子,继续抓自己的小网站,有空可以参观一下哈哈哈个人网站链接

路由表启示——我的新伙伴wireshark_第4张图片
我们看59包和61包,第一列就是包的序号。可以很明显的看到seq递增的规律。

TCP WIindows Scale

最早互联网很小,所以接收窗口是2^16 - 1个字节,但是时代在进步,现在这些不够用了,但是当初已经是用的16bit(位)来保存的无法扩展了,所以就产生了这个概念。只有在第一次和第二次握手的时候才有这个值。shift count意思是移位计数,就是2的多少次方,这里是7,意为着以后接收窗口大小要乘以2 ^7方。
路由表启示——我的新伙伴wireshark_第5张图片
这个就是接收窗口大小了,第三次握手也会有这个字段,2 ^7次方 * 229就是29312就是接收窗口大小的下面的那个值
路由表启示——我的新伙伴wireshark_第6张图片

RTO

发送包到重传发包的时间就是RTO
路由表启示——我的新伙伴wireshark_第7张图片

对TCP的新理解

以前总是不懂为什么要理解TCP协议,为什么面试要问TCP,为什么对日后工作很重要,只因为看的都是理论书并没有与具体项目结合,而wireshark分析这本书真让我明白了TCP的魅力了。

我们要努力避免发生拥塞,尤其是记住超时重传对性能影响是巨大的,因为一旦超时重传了就进入慢启动状态了,MSS就只是1了。无拥塞的时候,窗口越大(MSS越多)效率越高。

快速重传对性能影响小一些,但也要警惕小文件,小文件重传比大文件重传更烦人,我们都知道3次同一个ACK就触发快速重传,可小文件他可能只有一个mss,触发不了ACK啊,只能走超时重传了,所以性能就下来了。。

快速重传的新理解

以前就知道三次ACK就意味着这个包丢失了,就把这个包传过去,那如果发送序号为2,3,4,5,6,7,8这些包,2,3都丢失了如何传?又学会了SACK这个标记,表明收到包的左边界和右边界,这样就可以快速传序号2,3包,而不是传完2号包等ACK3,或者2之后包都重传一遍。3个ACK是为了避免乱序到达误触发快速重传,一般乱序达到不会超过3个及以上,所以确认ACK是3

nagle新理解

以前就是知道会把很多小块聚集到一个段里,然后在发送出去。但何时发送却一直没有思考过。nagle原理是发出去数据还没有收到ACK又有小数据的做法。当填满了一个MSS或者收到ACK都会立即发送数据出去。这时候你可能在想如果第一个窗口数据加载到内核缓冲区但不够一个MSS段岂不是不发送数据了?别急,在读一遍nagle原理,发送出去了数据,意思是第一次发送数据是不会触发nagle算法的。

排错指南

总结一下阿满的排错方式

  1. 首先通过数据图看又没有超时重传,毕竟超时重传很影响性能。
  2. 再看快速重传问题,很多时候是因为乱序导致重复ACK在导致快速重传,也有可能是包真的丢了
  3. 再看延迟确认(收到一个报文段隔了很久才发送ACK的和nagle(没收到ack就不会数据,收到ack就立刻发可以考虑nagle)。
  4. 再看看双方的接收窗口,是不是太小了。现在win size已经突破2^16-1的限制了,记住是看上面所述scale了。
  5. 大包过不去,小包可以过,考虑是不是MTU太大了,端与端选个最小的但不保证链路上的设备都比最小值大。
  6. 还有可能是开启LRO属性,让网卡工作慢带来的效率问题。
  7. NAT转换的问题
  8. 防火墙没开通端口
  9. 有的包正常有的包直接发送RST了,还可以观察TTL,看看RST包的TTL是不是和正常包的TTL一致。如果不一致在内网中可以看一下网络拓扑排序

你可能感兴趣的:(linux下工具,wireshark,网络,测试工具)