WireShark抓包图解探索网络请求过程（五层网络模型三次握手滑动窗口协议）

Posted 2022-08-01 鸽一门

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了WireShark抓包图解探索网络请求过程（五层网络模型三次握手滑动窗口协议）相关的知识，希望对你有一定的参考价值。

当我们在浏览器输入URL点击确认后，浏览器展示出网页信息。可你曾想过这其中的过程是怎样的？理论性较强的朋友可能知道后续DNS会解析地址，然后TCP/IP三次握手建立起连接，紧接着客户端与服务器开始传输数据。不错，大致过程确实如此，可终究“眼见为实”，此篇文章重点在于亲自实践，通过WireShark抓包来图解探索网络请求的整个过程，通过实践来更透彻的认识网络模型、三次握手、滑动窗口协议等理论知识在实际中的运用。

此篇涉及到的知识点如下：

五层网络模型
TCP/IP三次握手
滑动窗口协议
WireShark抓包探索

一. 网络理论知识

在使用WireShark抓包实践之前，先来学习以下基础的理论知识点作为基础。

1. 网络模型

首先通过一个简单的例子来了解网络架构，如下图所示，Tom想给Jerry发送一份可靠、安全的信息，但是实际上拥有的物理线路并非是可靠安全的，我们需要解决的就是在此之上建立一个可靠、安全的传输渠道。

（1）网络传输架构

而其中依赖的就是七层架构，来具体查看其原理：

物理层：最下面一层节点之间不可靠、安全的传输就是物理层。
数据链路层： 首先搭了一个数据链路层，既然节点之间传输数据不安全，那么需要一个单位（数据包），通过奇偶校验或其它方法来检验包是否正确，由此完成了一个节点到另外一个节点之间数据包的传递。
网络层： 如果Tom和Jerry都在一个房间内，那么数据链路层足够，可是如果是其它地区、国家，这就不仅仅是两个节点之间传输，需要一个网络层。网络层有路由，Tom会把包发给房间的路由器，路由器再传输给其它路由，辗转很多层后最后到Jerry所在的电脑上。这就是网络层的工作，同时为了标识在网络层中的各个节点，使用了IP协议，使每个节点都有IP地址。
传输层： 虽然在数据链路层可以确定包是否正确，但不能保证是相对可靠的，此时需要重传机制在错误时可以自动重传这个包，而不需要Tom人工确认，这就需要传输层。由此产生了对应的TCP、UDP协议。TCP协议是基于连接的，在Tom和Jerry传输之间建立一个可靠的连接，在此连接上传输数据。
应用层：以上过程确实可以传输可靠的数据，但是这个数据是为哪个应用服务的呢？是HTTP还是STP或者email协议，这就是应用层。

由此完成了上图中的五层架构，而七层架构中的其余两层被淡化，暂时不列出来，但是以上架构是解决网络问题最优方案吗？

并非如此，现在已知五层或七层架构是建立与不可靠、不安全的传输上，那为何不从最底层使得它可靠、安全呢？但是在网络发展过程中都是一层层地来解决问题，时从实践问题出发而并非理论，所以才有了往上叠加的网络协议、架构。回望计算机的历史发展，都是一层层地迭代进化而不是一开始就可以设计出完美方案，例如Java语言的泛型。

（2）网络传输的可靠、安全性

一开始就强调了网络传输并非是可靠、安全的，具体体现如下：

不可靠性：（在TCP协议中对以下3个不可靠因素提供了解决方案）
- 丢包、重复包：发送包对方并未收到或是收到重复包。
- 出错：传输时出错，只能通过重传来解决。
- 乱序：包是按照顺序发送的，对方接收时顺序打乱。
不安全性： 网络传输一定是一个不安全的线路，因为网络层将数据发送给另外一个节点，需要经过很多路由器，每一个路由都有可能被黑客监听。（不同于电话传输，所有的交换机在机房，网络上只需要一个无线路由器就可以监听手机的对外传输）
- 中间人攻击
- 窃取
- 篡改

2. TCP三次握手(TCP Three-way Handshake)

TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接。

（1）TCP标志位

TCP在其协议头中使用大量的标志位或者说1位（bit）布尔域来控制连接状态，一个包中有可以设置多个标志位。

位码即TCP标志位，有6种标示：

SYN (synchronous)： 创建连接
ACK (acknowledgement）： 确认接收到的数据)
PSH (push)：传送
FIN (finish)：结束连接
RST (reset)：重置
URG (urgent)：紧急
Sequence number(顺序码)
Acknowledge number(确认码)

（2）握手过程

定义：三次握手，是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。

目的：是连接服务器指定端口，建立TCP连接,并同步连接双方的序列号和确认号并交换 TCP 窗口大小信息

在socket编程中，客户端执行connect()时，将触发三次握手。

第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据.

3. 滑动窗口协议

此部分进行的讲解重心还是放在网络传输的可靠性，仔细探究TCP协议是如何解决网络传输的不可靠问题，其中有个非常关键部分——滑动窗口协议，同时可验证网络学科的实践性、工程性。

（1）滑动窗口协议的特征定义

TCP协议中使用
维持发送方/接收方缓存区

此缓存区主要用于解决网络传输的不可靠问题，在上一点已经介绍过网络传输的不可靠问题，如丢包、重复包、出错等，在TCP协议中发送方、接收方各自维护自己的缓存区，互相商定包的重传机制，由此解决不可靠问题。

（2）提出问题

如果没有滑动窗口协议，如何保证接收方能够收到正确有序的包？

如上图所示，发送方发送包1，接收方确认包1，发送包2，确认包2，这样即可解决不可靠性问题。但同时此过程的问题十分明显：吞吐量低，必须要等接收方确认完后才能发送下一个包。试考虑，若能连发几个包，接收方可以同时确认，这样效率岂不更高？

（3）简单改进

在此问题上，出现了以下改进：发送方可以同时发多个包，接收方一起确认。

（4）深度改进——滑动窗口实现

由此又衍生出一个问题，同时发包的数量多少才会是最优方案呢？例如发送方同时发送包1、2，在获得接收方确认包1消息后，能否不等包2确认信息，直接发送包3呢？

这样很自然地思考到了“滑动窗口实现”。以下有16个数据包，发送方希望按照顺序发送，在接收方收到每个包后都逐一给予确认：

初始：（窗口为4到7）
- 1、2、3包已发送并且获取发送方Ack确认；
- 4、5、6、7包已发送但尚未获取发送方Ack确认；
- 8、9、10包待发送；
- 而11、12、13、14、15、16包未发送甚至都没有装入内存；
正常：（窗口为5到9）
- 1、2、3、4包已发送并且获取发送方Ack确认；
- 5、6、7、8、9包已发送但尚未获取发送方Ack确认；
- 10、11包待发送；
- 而12、13、14、15、16包未发送甚至都没有装入内存；

丢Ack：（窗口为5到11）
- 5、6、7、8、9包未收到Ack（丢Ack），在等待过程又发送了10、11包，此时窗口已满，无法读进包12，只能等待Ack。如果真的是丢包，始终无法收到Ack，此时超时重传机制会从包5开始重新发送。（注意，这里的Ack是按照顺序发送的！）
重发：（窗口为9到15）
- 5、6、7、8包获取发送方Ack确认；
- 9、10、11、12、13包已发送但尚未获取发送方Ack确认；
- 13、14包待发送；
- 而16包未发送甚至都没有装入内存；

（5）总结

运用工程学的思想来考虑滑动窗口机制较为容易，为了增加线路的吞吐量，改进原版方案，令发送方同时发送包；为了衡量同时发送的数量达到吞吐量最优解，从而引进滑动窗口机制；为了解决丢包等不可靠性问题导致发送方无法收到接收方的Ack，又引进了重发机制。以上一系列过程使得整个传输过程更加可靠。

TCP采用的滑动窗口？

a. 是3位的滑动窗口 ( N )
b. 仅用于流量控制 ( N )
c. 在传输过程中窗口大小不调整 ( N )
d. 大小为0是合法的 ( Y )

二. WireShark 网络抓包示例

WireShark是很有名的抓包软件，基本的操作指导不做过多讲解，这里主要将重点放在其抓包的数据，由此分析网络模型组成及相关原理。

1. 网络请求访问（73、74号DNS包）

首先打开wireshark软件，会出现许多接口interface，选择本机连接的网络进行捕获，访问新浪网：http://www.sina.com/（注意这里的地址是国际版的，未带cn），这里建议在Chrome中的隐身窗口中访问，避免浏览器中缓存的干扰！访问后停止捕获。在其内容中搜索字符串“sina”，第一条就是捕获到的数据，点击查看具体内容组成。

（1）解析73号DNS数据包

这是一个DNS数据包，代表若我们要访问新浪网，首先要通过DNS的请求然后到新浪网的IP地址，来具体查看数据包所含内容：

a. Frame 73: 80 bytes on wire (640 bits), 80 bytes captured (640 bits) on interface 0
这是物理层，Frame 73代表这是第73号数据包，大小为80，内容如下图所示，

b. Ethernet II, Src: IntelCor_37:44:c0 (34:de:1a:37:44:c0), Dst: HuaweiTe_71:8a:98 (00:46:4b:71:8a:98)
数据链路层的报文头及相关协议（还有PPP 和PPPOE协议），它的Src是IntelCor_37:44:c0 ，这其实是我的笔记本，windows系统（若是mac，则是Apple开头的）；而Dst中的是我电脑连接的网络路由。

虽然这是DNS的一个query，但是无法访问我的路由，最终是传到外面DNS的路由，在数据链路层只是将包从笔记本传到路由，这个包会由路由器进行转发。

c. Internet Protocol Version 4, Src: 27.18.155.45, Dst: 202.103.24.68
网络层即IP层的头。很熟悉的IPV4协议，Src是我连接的Netkeeper网络的IPV4地址，Dst是DNS服务器地址。

d. User Datagram Protocol, Src Port: 60889, Dst Port: 53
传输层中UDP协议的头。 这个DNS的请求是作为一个UDP包发送，不需要预先建立连接。
e. Domain Name System (query)
DNS的query内容。以上讲解的UDP包中的内容就是DNS的query部分，由以下二进制数据表示，根据协议会规定每个字节代表什么含义，wireshark会翻译出每个字节的含义，例如下图中：

Transaction ID是0xe231
Questions数量为1，www.sina.com新浪网的地址。（意味着还可以有多个Questions）
Response响应在65号包。

（以上字节内容都是wireshark分析得出的结果）

（2）解析74号DNS数据包

由以上分析可得响应内容在74号数据包，来查看：（只解释重点内容）

Ethernet II, Src: HuaweiTe_71:8a:98 (00:46:4b:71:8a:98), Dst: IntelCor_37:44:c0 (34:de:1a:37:44:c0)
数据链路层的报文头及相关协议（还有PPP 和PPPOE协议），很明显后面的src内容是本地路由。
Internet Protocol Version 4, Src: 202.103.24.68, Dst: 27.18.155.45
IP层。scr是DNS服务器地址，Dst是本机IP，代表dns将包发送到本机。
Domain Name System (response)
应用层。查看下图DNS的response内容，Queries是本机请求新浪IP，而Answer有3个地址。

对比查看，发现DNS的response中的Answer提供的IP地址（66.102.251.33）与75号TCP数据包IP相对应，说明我们可以从Answer第三个信息连上！获取到新浪网的IP地址后，需要开始建立连接。

2. 与新浪网建立连接，进行网络协议中的3次握手（75、76、77号TCP包）

经过以上分析后，接下来在wireshark中搜索只有关于IP地址的信息（搜索ip.addr==66.102.251.33）。如下图，这样即可查看笔记本电脑与新浪网的交互过程：

来分析75、76、77号TCP包，查看其Info部分：

第一个包标志为 [SYN]
第二个包标志为 [SYN，ACK]
第三个包标志为 [ACK]

对网络知识有过了解的肯定知道这就是网络协议中的3次握手，来依次查看：

（1）75号TCP包

此包是第一次握手具体内容，来查看：

数据链路层（Ethernet II）：包是从本机发送到路由。
网络层（IPV4）：将包发送给新浪网。
传输层（TCP）：（查看下图）
- Destination Port目的地端口号为80，即试图和新浪网的80号端口连接，80号端口是HTTP协议的端口，浏览器若要访问需要从HTTP获取信息。
- Sequence number 是包的编号为0，在博文的第二大点中滑动窗口协议已经介绍包的编号机制。
- Acknowledgment number为0，因为目前并未收到Ack。
- Flags 设置为SYN，代表连接的请求。
- Window size value是滑动窗口的大小，是8192。
- TCP Segment Len 为0，因为次请求只带了一个头部，内容为0，所以此包的长度除去头部之外为0。

（2）76号TCP包

继续查看第二次握手新浪网响应的包是什么，直接查看重点部分TCP内容如下：

Acknowledgment number为1，在TCP中1并不表示收到了包，而是说在等待、期待发送包，因为之前已经发送了第一个包，意味着包0已经收到，现在期待收包1。
- Flags 设置为（SYN，Ack），代表已经收到了连接请求，并且愿意进行连接
- Window size value是新浪网的滑动窗口大小，是4320。

（3）77号TCP包

继续查看第三次握手内容，我们直接查看重点部分TCP内容如下：

Sequence number 是包的编号为1
Acknowledgment number为1，说明收到了新浪网的0号包，现在期待1号包的来临。
Flags 设置为（Ack），代表确认连接。
Window size value调整滑动窗口大小为17280。

当此包被发送出去后，3次握手过程完成，本机和新浪网之间的消息在一个很可靠的TCP连接上进行。

3. 成功建立连接，开始GET请求资源（78号HTTP包）

接下来可以发送HTTP协议，查看wireshark之后证实我们的言论，接下来确实是进行Http协议上的Get请求，直接查看78号HTTP包中重点内容。

（1）TCP内容

TCP Segment Len长度不再为0，而是369。
Sequence number 仍然是1，在TCP协议中并非按照1、2、3….这样来标识，而是按照发送字节的大小。例如当前是1，加上此包本身长度为369，所以Next sequence number 是370。
Acknowledgment number为1

（2）HTTP请求内容

如下图是一些基本的http请求内容，例如host主机名和请求的基本参数，稍作了解即可。

4. 本机与新浪网交互 —— 资源发送与确认Ack

（1）79号TCP包

TCP中内容：（这里需要重点关注此点即可）

查看上图，Acknowledgment number 为 370 ，表示从0~369之间的数据已接收到，从370开始发送。

（2）80、81、82号TCP包（发送）

接下来查看80、81、82号TCP三个包，是新浪网返回的数据，通过上图可知每个包大小都是1502，表示一个包发不完，所以分成几个包来发送。这里依旧将重点放在TCP内容中：

Sequence number字段：
根据下图这三个包中的Sequence number变化可知，3个包传递的TCP内容长度皆为1440，顺序号从1开始，逐渐变化增加。重点注意此字段变化：1 ->1441 -> 2881。（此部分结合后一点讲解证实了滑动窗口协议）

TCP segment data
TCP中传输的内容绝对是不会以明文的方式，通过此字段可知，Encoding编码方式是gzip，所以显示的数据都是乱码，浏览器收到后会自动进行解码。

（3）83、92TCP包（Ack）

重新回顾滑动窗口协议，新浪网在发送了80、81、82号TCP包后，需要等待接收方Ack！

下图是83、92TCP包中的TCP重点内容，这是接收方的Ack：

83包中的Acknowledgment number 为2881，注意对应上一点讲解的80、81、81号TCP包中的Next Sequence number字段可知：81个包中Next Sequence number长度为2881，意味着已有0~2880长度数据，所以83包的Ack代表同时确认了新浪网发送的81、82这两个包！
92包中的Acknowledgment number 为4321，对应着82号TCP包中的Next Sequence number字段。代表92包的Ack代表确认了新浪网发送的83包！

有时候是同时Ack两个包，有时候是Ack一个包，以上过程正是之前讲解的滑动窗口协议中的部分呈现。