跳至主要內容

基于WireShark的网络分析

PPLong大约 9 分钟

基于WireShark的网络分析

一直对网络抓包这块很感兴趣，并且WireShark也一直吃灰，借这个机会通过WireShark分析一下传输层和网络层（TCP、IP）具体到数据包的封装细节和具体的工作细节

介绍

WireShark

前称Ethereal，是一个网络封包分析软件，截取网络封装包，尽可能详细地显示网络封包信息 开源开源开源！

网络分析

三次握手

主要看传输层的分析

Hello

报文首部结构在这里，可以一一对照

image-20210914163318606
image-20210914163318606
image-20220331162210966
image-20220331162210966

解释一些之前不太懂的含义：

  • 源端口号是从Linux较靠后的“客户端端口”范围随机提供的（为什么有源端口？->找得到回来的路），到哪去，肯定是到为HTTP开放的80端口上。
  • 序列号：客户端系统随机产生的32位，这里wireshark优化了一下 提供了相对的值
  • 确认序列号：为0，因为是我请求，不需要确认什么
  • Flag：
    • SYN打开表示建立连接，仅SYN为1的包为SYN包，只有服务端受到客户端发来的SYN包，才可以建立联系
  • 接受窗口大小：指定窗口大小
  • 检验和：TCP整体检验（包括载荷）[12字节伪首部] TCP首部校验和计算三部分：TCP首部+TCP数据+TCP伪首部
  • 选项：
    • MSS：[限定载荷数据长度]设置了自己的MSS值，以便与服务端进行沟通，选择最小值
    • SACK：允许优化的重传方式
    • Window Scale：表明自己的窗口扩大因子

I hear u

image-20220331165900512
image-20220331165900512

服务器返回的，从服务端的80端口到客户端指定的端口。这里Sequence Number是服务端选定的，确认号是在客户端的序列号的+1；由于是希望建立连接，所以SYN=1，且表示确认收到信息，所以ACK=1；表明了自己支持的接受窗口大小（这里<客户端）；表明了自己不同的MSS。其他信息意义都相同。也在Option中表明自己是否支持SACK

Let's talk

image-20220331170950616
image-20220331170950616

客户端向服务端表明我知道你能听到我了

序列号在之前自己发的原有基础+1（与学的不同？）确认号在对方发来的序列号基础上加1；Window size为正确的factor * size值（为什么是这个值？）

理解Ghost Byte

正常传输

发送HTTP请求

image-20220331171820581
image-20220331171820581

客户端向服务器发送HTTP GET请求，请求某URL下的资源；从这里开始就有payload了；确认号为之前服务端发来的序列号 +1；PSH（表明是该请求的最后一个数据包，方便通知应用程序及时从网络缓存中去拿数据）和ACK（表示响应，我收到你之前的消息了）都打开；Window Size 采用之前规定好的（但没有factor了，为啥？怎样能确保最终为size*factor?）

响应

服务端先回应我收到你HTTP请求的响应，序列号在服务端之前发送给客户端的基础上+1，同时还会有window size的调整。然后就另起数据包，开始发数据了

image-20220331190932943
image-20220331190932943

可以看到，确认号和序列号都不变，主要是有了payload，开始负载数据。且之后的传输中，确认号都等于对方的序列号+payload长度

窗口的应用

发现了有趣之处image-20220331191642232，此时Server同时传了两个TCP PDU给Client，但Client只用了一个ACK包就表明受到，这里就涉及到TCP的窗口知识了

最终在传完一整个请求的数据包时，Client返回最后一个数据包的ACK包，随之Server向Client传HTTP 200的响应包，（PSH和ACK = 1）到这里，对服务器来说，才算是把一个请求响应结束！。Client返回ACK包表示收到，（猜测可能会在这里浏览器会初步加载没有css js等的页面）。

然后Client可以开始发送新的HTTP请求，比如get css文件等

TCP Stream

在这里，对一个返回数据量较大的HTTP请求，WireShark会显示"TCP segment of a reassembled PDU"，这里其实对TCP的知识还不太熟悉。今天看了下先勉强解释下，与IP分片不同，因为一个返回数据量大的请求会把数据从TCP层拆分，他们具有不同的确认号和序列号，以类似流的形式持续达到目的端口，可在WireShark里“Follow TCP Streams”能够看到完整的数据包（对于一个网页请求，完整数据就是一个网页的html代码）。
🔗 WireShark的对TCP PDU的解释open in new window 🔗 What is Packet Reassemblyopen in new window

对之前的数据包来说，WireShark会标注[Reassembled PDU in frame:xxx]，其中xxx就代表的是HTTP 200等响应的回复，代表这是一个完整的数据

一个ACK包确认多个发送包

例如这里便用一个ACK确认了两个发送的包

image-20220405130940538
image-20220405130940538

异常情况分析

Sack

结构：在Option中，1字节表示类型，1字节表示该SACK部分占用字节长度，剩下的字节分别为左右edge的范围 一般总共为10个字节，最多携带3个SACK(留10个字节要给TimeStamp)

解释一下某些情况下Bytes in flight的猛增现象

刚看的时候一直被不按 未被ACK的包造成的Bytes in flight猛增现象搞混，分析了一下 。

image-20220405194323205
image-20220405194323205

例如这里，在经历两次Dup ACK 后，Bytes in flight从4194激增到50328，为什么？依次做减法：1122595 - 50328 = 1072267，正是考虑到其实有最初DUP ACK包的最小SACK的left edge值，说明了什么？其实是到上一个包发送的Seq + length 到 SACK left edge的差，令人惊讶的是，它把没有尚未接受的包也考虑在内

image-20220405195326028
image-20220405195326028

接下来也类似，尽管有两个SACK，但还是将最近包的Seq+length 与最初SACK的left edge做差，表明这之间的包没有收到。尽管两个SACK之间的包。

这里实践总结就是如果服务端在传大于ACK的其他包，则值为当前Seq+length - 最初SACK left edge；如果正在传当前要的ACK，则SACK最大值的left edge - Seq不过这里还未完全理解

**其实就是Server发送的，但Client还未接收到的数据的总和，不要搞得太复杂了 **

Dup Packet

TCP Duplicate Packet ：指示与之前已ack的包有相同的序列号和确认号，通常是带有SACK的。比如这里：

image-20220405144319645
image-20220405144319645

Server的637693、639091的数据包过快到达（之前的包可能因时延还未到达），但Client无法根据顺序接受这个包，TCP顺序不匹配，所以Client再发送一条ACK 包，确认号和序列号都与上一条相同，所以被标注为TCP Duplicate ACK (Packet)。
更有意思的是，其TCP Option中带有637693-640489的SACK，表明之前的两个包我有了，但是顺序不对，还没接到从我ACK开始的包

过多的Duplicate Packet指明可能当前网络丢包率较高

TCP Retransmission

一个典型的案例：image-20220405151110207

这里就比较清楚，之前传的15379的包Client一直没接收到，然后Client就不断的给Server发带有更新SACK的Dup ACK Packet，Server后来接收到这个包，知道自己之前发的15379的包可能loss了，所以重新发了一个15379的包

Congestion Control

拥塞控制：服务端负荷过重，请求过多

TCP Keep-Alive

长连接 保活，一段时间内一方未回应或未发包，就会发送一个Keep-Alive包 无载荷Seq与上一个包重合，如果对方在线，就会回一个包，来确保连接继续

Window Size

遇到一个坑点，自己用的梯子，所以去访问自己的服务器时，Window Size总是1398,并且访问其他的网站时，也都显示的是从某一个指定的网站上返回过来的数据，难怪去filter host却找不到对应的数据包，原来是我代理的问题，后来把代理改了应该就没有问题了

但有时候机器性能太好、网络 太好，导致无法捕获到Window Full情况，就需要手动调整Linux TCP的窗口大小：

Linux设置Window Size
  1. route -ne查看默认路由表。
  2. sudo route del default删除默认路由表
  3. sudo route add default gw 172.20.10.1 window xxx dev wlo1，增加新的路由表，带有window约束

（会发现网页的加载都变慢许多）还有一些方法是临时修改/etc/sys/net下的文件，没试过怕改错。

四次挥手

为了直观了解挥手情况，不受其他因素影响，这里我采用的是从ssh断开连接的情况

输入exit后，敲入回车，Client给Server发回车的数据包，Server发相应的数据包在terminal中显示；Client发ack报表示已经接受

第一次挥手

Client - > Server：客户端完成了所有请求，要求断开。FIN 和 ACK均置为1，确认号还是对方发的上一个包的序列号+payload.length

image-20220331200819661
image-20220331200819661

第二次挥手

Server -> Client：表明我已经接收到你的结束请求，ACK=1

image-20220331220424436
image-20220331220424436

第三次挥手

Server->Client：表明“那我也走了”，与Client类似，设置FIN和ACK=1，这时确认号要在第二次的基础上+1

image-20220331221931572
image-20220331221931572

第四次挥手

Client -> Server：客户端说我也知道你要走了，发送后进入2MSL后，进入CLOSED状态。Server接受到这个数据包时，不再发数据包，进入CLOSED状态

对四次挥手的细节及原由 移步《计网》

Telnet过程

SSH过程

基于docker的SSH过程

FTP过程

网络拥塞控制分析

DNS过程

TLS过程

为什么在三次握手后会有Client Hello

默认页脚
Copyright © 2024 PPLong