Mac端Wireshark抓包工具使用扩展

昨天记录了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中设置。