Mac端Wireshark抓包工具使用扩展

发表于:2019-1-17 11:47

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:CharlieWang    来源:思否

  昨天记录Wireshark的基本安装配置。今天开始真正的使用起来。
  前言
  关于网络协议和网络分层,本篇文章不做介绍,仅记录使用,可能中间有理解错误的地方,请指正。
  开始
  一般常规的网络请求对包的大小是有限制的,即MTU"最大传输单元",大多数网络的MTU是1500字节,也有一些特例的巨帧达到9000字节。假如现在有一个8000字节的数据包进入网络,如果是巨帧网络,数据可以传输成功,但是如果进入到1500字节的网络中,就会被丢弃或者切分。重传还是会被丢弃,无法传输成功。
  TCP为了解决这个问题,不是一次把8000字节的数据传给网络互联层,而是根据双方的MTU决定每次传多少。如下图所示,在TCP三次握手的时候,双方会吧自己的MSS(Maximum Segment Size)告诉对方,MSS加上TCP头和IP头的长度,就得到MTU。
  
  在NO.11的包里,客户端声明自己的MSS是1460,则它的MTU就是1460 + 20(TCP头)+20(IP头) = 1500字节
  在NO.12的包里,服务器声明自己的MSS是1452,意味着MTU是1452 + 20 + 20 = 1492。
  TCP/IP的头信息请自行查看网络协议书籍文章。
  TCP头结构如下:
  
  IP头结构如下:
 
  TCP分包
  前面介绍了在三次握手时,双方会把MTU告诉对方,下面看下实际的数据传输。
 
  在第一行的包中数据len=1452(红色划线部分),而前面的红色框中显示的长度为1492,和前面说的结果一致。
  下面可以看到更多的信息,黄色框圈出来的是当前的序列号为1,下一段的序列号为1453,刚好是加上1452的长度。绿色框可以看到本次传输的长度。在上方的列表红框的右侧也可以看到长度和Seq信息。
  还可以看到发起接收的端口信息。
  经过测试,可以看到数据包最终的大小是按照服务端的MTU来分割的。也就是发包的大小是由MTU较小的一方决定的,那怕客户端的MTU是9000,也只能用1492的大小去发包。
  更多信息
  
  上图是我从服务器获取图片的一个请求,可以看到很多信息。下面简单解析下。
  感叹下:之前看网络协议感觉很懵逼,枯燥。对着wireshark明朗多了。
  NO.12293 - NO.12295行是HTTP的连接过程,可以看到客服端的MSS是1460,服务端的MSS是1452,这前面都讲过了。
  NO.12296指明了这次请求是GET。平时用AFN这么久,POST、GET大家也都耳熟能详。下面就继续看下GET背后的逻辑是什么。
  NO.12297:服务端发出的确认连接信息(有疑问,这一个包我也不太清除。)len=0,seq=1,所以下一个包的Seq = 1 + 0 = 1。就是NO.12300的Seq。
  NO.从12297直接到12330,应该是中间还有其他的包请求,我为了方便看,对数据请求做了筛选,只显示这次图片请求相关的。
  从NO.12300到NO.12303是服务器在向客服端发送数据,可以看到Seq和len的变化。NO.12303有点特殊,与另外几个相比,多了个PSH字段。这是TCP的状态标识)。
  TCP层有个FLAGS字段,有以下标识:SYN,FIN,ACK,PSH,RST。
  SYN:建立连接,因为连接是双向的,所以建立连接时,双方都要发一个SYN.
  FIN:关闭连接,同SYN,因为双向,所以关闭,双方都要发一个FIN.
  ACK:响应,
  PSH:data数据传输,
  RST:连接重置。用于重置一个混乱的连接,或者拒绝无效请求.平时抓包要特别注意这个字段。
  具体含义和组合意义自行搜索,或者点击上面的“TCP的状态标识”查看
  NO.12304和NO.12305是客服端的呼应,看NO.12305行:
 Seq = 243 ACK = 5788 Win = 256320 Len =0
  ACK值
  ACK = 5788,5788 值是从NO.12303里面得到的,
   NO.12303:
  Seq = 4357 Len = 1431.
  4357 + 1431 = 5788.
  NO.12305行的ACK = 5788意思告诉服务器,已经收到了5788以前的数据。理论上,接收方回复的ACK号恰好等于发送方的下一个Seq号,看NO.12307行。刚好一致。
  仔细看列表会发现,服务端发出了4个数据包,但是客服端只发出了两个应答。这是应为ACK = 5788代表把之前的包都确认了,TCP的确认是可以累积的。
  Seq值:
  看上面的截图,会发现Seq的值不统一,因为TCP是双向的,在一个连接中,双方都可以是发送方,所以各自维护了一个Seq.截图上Seq一直变大的是服务端,因为在传输图片数据。没变化的是客服端,只是做了个应答,每次应答的Len=0,所以就没有变化,一直是243.而且这个243也不是凭空出现的。看NO.122295和NO.12296,可以计算出来。
  到现在为止,我们已经可以很好的检查网络数据的乱序问题了,只要根据Seq号就可以比对数据是否有丢失和乱序。
  One more thing
  哈哈,想到了每次WWDC的One more thing,借来用下。
  重新看上面的请求列表。三次握手建立的时候,Seq= 0,而事实上,握手时Seq并不是从0开始。之所以在 Wireshark 上看到Seq = 0,是 Wireshark 默认开启了 Relative sequence numbers,如果想关闭,在Wireshark ->Preferences -> protocols -> TCP中设置。
 

     上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号