Wireshark——从此我就喜欢上了它，就像是学武之人得到了一把称手好剑

最新推荐文章于 2022-03-02 19:19:15 发布

hello_读书就是赚钱

最新推荐文章于 2022-03-02 19:19:15 发布

阅读量598

点赞数 2

分类专栏： Wireshark 文章标签： Wireshark Wireshark书籍

本文链接：https://blog.csdn.net/hayre/article/details/101950708

版权

Wireshark 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

在之前的工作中，常常遇到一些应用层无法解决的问题；连接被中断，重置，应用层程序只报了连接超时的错，问题究竟是出在服务器端，还是边界，无从得知。用了一段时间的Wireshark抓包，终于发现一些线索。意识到Wireshark的强大之处，利用假期时间，读了《Wireshark网络分析就这么简单》受益匪浅。

我是带着看一下Wireshark怎么用、参透TCP协议两个目的去阅读该书的。

本以为该书是简单的使用手册，却发现更像是实战，是对问题定位的思路与排查过程的记录，非常能引起作为技术人的我的共鸣。特别是其中一章，用了深入浅出的语言讲解了TCP协议的相关知识，填补了我对这一块知识的空缺（常见的TCP协议面试题都可在这一章中找到答案）。除此之外，该书一直强行安利《TCP/IP协议卷》，激起我强烈的阅读TCP/IP协议卷一的兴趣。摘抄了三句书中的句子，这三句足以表达看完该书之后的欣喜之情。

假如真的能遇到棘手的难题，我建议用Wireshark分析。一旦用它解决了第一个问题，恭喜你，很快就会中毒上瘾的。你可能碰到什么问题都想抓个包分析，就像小时候刚学会骑车一样，到小区门口打个酱油都要骑车去。

从此我就喜欢上了Wireshark，就像是学武之人得到了一把称手好剑。

在网络时代，有些人就算从来没有机会见面，甚至不知道年龄和种族，也可以是最好的老师。

下面知识点，是在两次阅读后，得出的心得体会，解决问题思路总结，关于TCP层知识点总结。

一、关于抓包

Wireshark界面：含列表、包头、包内容体

1、传输层协议无非TCP/UDP，我们可以从流中看出协议定义的交互过程，这是学习某种协议的最好方式，这让我联想到前几天研究RTMP协议（一种基于TCP的视频协议），也是通过抓包看到其作用过程。

2、断定问题思路、从源IP、目标IP可以看到是否是配置问题，曾经遇到的一个问题就是因为配置写错，导致数据一直写到一个错误的MQ里面去，是组里的大牛通过抓包，才一眼看到了问题。从包头，可以看到异常包信息，其中有包重置，包重传，窗口降为0等等。

3、抓包时，我们可以限制包的大小，可只抓包头，定位问题一般与包体无关,专家建议限制大小为80，解决了我之前对大文件传输包抓取的恐惧

tcpdump -Ann -s 80 host XXX.XXX.XXX.XX

4、分析时，IP过滤，端口过滤，协议过滤

分析时：

使用专家分析
查看响应时间统计表
查看TCP流统计图

二、关于网络分层

书中讲解了网络分层，最大的感受是，OSI7层已经被丢弃了，常用TCP/IP 4层描述问题。至于这个知识点有研究过，就不再累述。
在这里插入图片描述

三、关于TCP协议

1、常见的状态字

MTU：最大传输单元

MSS：最大段长度

MTU=MSS+TCP头长度+IP头长度

Seq：表示该数据段的序号

TCP提供有序的传输，故需要标上一个序号
增长方式：一个Seq号的大小是根据上一个数据段的Seq号和长度相加而来的

在这里插入图片描述
Len：该数据段的长度，不包括TCP头。头部本身携带信息很多，不要以为len=0就没意义

ACK：确认号，接受方向发送方确认已经收到哪些字节。TCP的响应是可以累积的

SYN：携带这个标志的包表示正在发起连接请求

FIN：携带这个标志的包表示正在请求终止连接

RST：用于重置一个混乱的链接，或拒绝一个无效的请求

2、三次握手的过程

在这里插入图片描述

客户端：“我能跟您建立链接吗？我的初始发送序号是X。如果你答应就Ack=X+1”

服务器端：“收到啦，Ack=X+1。我也想跟你建立链接。我的初始发送号是Y，你如果答应连接就Ack=Y+1”

客户端：“收到啦，Ack=Y+1”

3、四次挥手过程

客户端：“我希望断开链接（请注意FIN标志）”

服务器：“知道了，断开吧”

服务器：“我这边的链接也想断开”

客户端：“知道了，断开把”

4、滑动窗口机制

TCP窗口快递员的工作策略，快递员送快递，运输的数量有限，目标的接受容量有限，需要解决一次运输多少的问题，一口气能发送的数据量就是传说中TCP发送窗口

交互时，可以把自己的接受窗口告诉对方，过程如下：

客户端：“当前我的接受窗口是2920”

服务器：“（好，那我的发送窗口就定位2920）先给你1460字节”

服务器：“再给你1460字节。（哎呀！我的发送窗口2920用完了，不能再发了）”

客户端：“你发过来的2920字节已经处理完毕，所以现在我的接受窗口又恢复到2920”

服务器：“（好，那我的发送窗口就定位2920）先给你1460字节”

服务器：“再给你1460字节。（哎呀！我的发送窗口2920用完了，不能再发了）”

一些注意点

发送窗口！=接受窗口，只会向对方申明自己的接受窗口
滑动窗口机制，说的就是这两个窗口的关系
假如接受方处理数据的速度跟不上接收数据的速度，缓存就会被占满，从而导致接受窗口为0 ，曾经我在抓过的包上面，看过，断定服务器负载到极限
我们是无法从包里看出发送窗口的大小的，且发送窗口的大小是靠严格的算法算出来的。
发送窗口决定了一口气能发多少字节，而MSS决定了这些字节要分多少个包发完，在一个窗口发出n个包，不一定就能接受到n个确认包，是因为服务器端有延迟确认机制~。
TCP Window Scale：作用是向对方声明一个Shift count，我们把它作为2的指数，再乘以TCP头中定义的接受窗口，就得到真正的TCP接受窗口。解决了TCP头定义的接受窗口最大为65535的问题。
wireshark 显示的win=XXX是根据Window Scale结果计算出来的。

5、关于重传

5.1、相关概念

拥塞点：能导致网络拥塞的数据量

拥塞窗口：网络对发送窗口的限制，就是通过拥塞窗口实现的

5.2、发送窗口的变化过程

（1）链接刚刚建立的时候，发送方对网络状况一无所知。如果一口气发太多数据就可能遭遇拥塞，所以发送方把拥塞窗口的初始值定的很小。RFC建议是2、3、4个MSS
（2）如果发出去的包都得到确认，表明还没达到拥塞点，可以增大拥塞窗口。这时，发生拥塞概率低，使用2的倍数增长，这个过程称为慢启动，这个过程赠速快，但是基数低，传输速度还是比较慢
（3）慢启动过程持续一段时间后，拥塞窗口达到一个较大的值。这时候传输速度比较快，触碰阻塞点的概率大，减少传输速度了。RFC建议是在每个往返时间增加1个。这个过程称为拥塞避免。临界窗口取值很有讲究，需要一定的算法。

5.3、超时重传

拥塞之后，发出去的包不像往常一样的到确认了，发送方等待一段时间后，还收不到，认定包丢失。这个时候称为超时重传，从发出原始包到重传改包的这段时间称为RTO
在这里插入图片描述

重传之后的拥塞窗口需要调整，RFC：建议把拥塞窗口降到1，然后再次进去慢启动过程。

关于临界窗口：

Richard Stevens：把临界窗口值定位上次发生阻塞时的发送窗口的一半。
RFC 5681：发生拥塞时没有被确认的数据量的1/2（更加科学）

超时重传对传输性能的严重影响：

RTO阶段不能传输数据
拥塞窗口急剧减少

5.4、快速重传

快速重传：除丢失的包外，后续有包能正常到达。当后续的包到达接收方时，接收方会发现其Seq号比期望的大，所以它每收到一个包就Ack一次期望的Seq号，以此来提醒发送方重传。当发送方收到3个或以上重复确认（Dup Ack）时，就意识到相应的包已经丢失了，从而立即重传它。这个过程称为快速重传。之所以称为快速，是因为它不像超时重传一样需要等待一段时间。

凑满3个的原因：因为网络包有时会乱序，乱序的包一样会触发重复的Ack。由于一般乱序的距离不会相差太大，所以限定成3个或以上可以在很大程度避免因乱序而触发快速重传。
在这里插入图片描述

快速重传后拥塞窗口的调整：RFC 5681认为临界窗口值应该设为发生阻塞时还没被确认的数据量的1/2。然后将拥塞窗口设置为临时窗口值加3个MSS，继续保留在拥塞避免阶段。这个过程称为快速恢复
在这里插入图片描述

5.5、快速重传之后的策略

更复杂的情况，丢的包并不只一个。对于发送方来说，只能通过Ack2知道2号包丢失了，但并不知道还有哪些包丢失。在重传了2号包之后，接下来应该传哪一个呢？
在这里插入图片描述

方案1：将3、4、5、6、7、8都重传一次（效率低，早期的协议就是这样处理的）
方案2：NewReno：接受方收到重传过来的2号包之后，会回复一个Ack3，因此发送方可以推理出3号包也丢了，把它重传一遍。当接收方收到重传的3号包之后，因为丢包的窟窿都补满了，所以回复一个Ack9，从此发送方就可以传新的包（当丢包量很大的时候，就需要花费多个RTT（往返时间）来重传所有丢失的包）
方案3：SACK：接收方在Ack2号包的时候，顺便把收到的包号告诉发送方。因为发送方对丢包的细节了解，在快速重传2号包之后，它可以接着传3号，然后再传9号包。