2023年7月3日发(作者：)

wireshark抓包分析从浏览器输⼊URL开始，直到请求到⽹页数据的数据包传输过程环境： win10, ⾕歌浏览器，wireshark2.6.0电脑通过⽹线接⼊⽹络，IP地址为10.112.228.49IPV4 DNS地址为10.3.9.4或者10.3.9.5，此外，浏览器所在⼦⽹的⽹络号为前16 bytes, 即10.3待请求的URL: (这⾥其实是/，表⽰⽤https协议传输，HTTPS实际上应⽤了Netscape的安全套接字层（SSL）作为HTTP应⽤层的⼦层。因此，这⾥的数据包通信与http协议有⼀点不⼀样)1. 打开wireshark，选择下图中的⽹卡。并且在⾕歌浏览器的⽆痕窗⼝中输⼊。红线上的⽹卡对应的IP地址为10.112.228.492. 数据包分析第100个数据包表⽰本机向DNS服务器发送DNS请求，请求的IP地址，此DNS消息通过UDP传输⼀般来说，浏览器在解析域名时，会⾸先查看1) 本地硬盘的hosts⽂件。若hosts⽂件内有域名和IP地址的对应关系，则直接使⽤该IP地址通信。若没有，则浏览器会发出⼀个 DNS请求到2) 本地DNS服务器。本地DNS服务器⼀般由⽹络接⼊服务器商提供，中国电信、中国移动等。本地DNS服务器⾸先查询缓存记录。若缓存中有域名对应的IP地址记录，则直接使⽤该记录返回IP地址。若没有，则本地服务器向3) DNS根服务器查询。DNS根服务器没有记录具体的域名和IP地址的对应关系，⽽是告诉本地DNS服务器，可以到4) 域服务器上去继续查询，并给出域服务器的地址。域服务器收到请求之后，也不会直接返回域名和IP地址的对应关系，⽽是告诉本地DNS服务器，5) 域名的解析服务器的地址。最后，本地DNS服务器向域名的解析服务器发出请求，这时就能收到⼀个域名和IP地址对应关系，以备下次别的⽤户查询时，可以直接返回结果，加快⽹络访问。

第102个数据包表⽰DNS服务器回应第100个数据包中的DNS请求，仍然⽤UDP协议传输，表明域名对应的IP地址如下，⼀共有8个由第104个数据包可以看出，本机选择了58.205.221.227的IP地址, 由此可知，通信双⽅（即浏览器与简书服务器⽹络号不同，即不在同⼀个⼦⽹）。此外，由Info内的标志位[SYN], [SYN,ACK], [ACK]可以看出第104，第105，第106三个包为TCP三次握⼿的过程第104个数据包为第⼀次握⼿，可以看到⾃⾝的seg = 0, 这⾥还可以观察到，数据链路层的MAC地址都是RuijieNe_7d:fd:ab，LcfcHefe 37:82:f5没有变化，说明mac地址⼀直都是本机⽹卡与局域⽹⽹卡之间通信使⽤的第105个数据包为第⼆次握⼿，服务器端的seq = 0；对浏览器seg的确认为Acknum = 1第106个数据包为第三次握⼿，客户端回复的Acknum = 1SSL握⼿客户端向服务器发送SSL协议封装的包client Hello，SSL在传输层对⽹络连接进⾏加密， 它建⽴在可靠的传输协议（如TCP）之上，为⾼层协议提供数据封装、压缩、加密等基本功能的⽀持。包⼤⼩为517，客户端的窗⼝⼤⼩为66048服务器给客户端发送⼀个长度为o的确认包，表⽰服务器seq = 1; Acknum = 518表⽰已经收到了前517个数据包，下⼀个数据包从518开始吧，此外，服务器的窗⼝⼤⼩为30720.服务器向客户端发送server Hello, 段长度为1440，因此客户端对服务器要求的下⼀个窗⼝的起始位置可以为1441，服务器的接收窗⼝为30720，服务器已确认来⾃客户端的前517个数据包，下⼀个报⽂从518开始服务器端向客户端发送SSL封装的数据段，段长度为1440，服务器的seg = 1441, 下⼀轮传输可以从2881开始服务器server Hello Done,向客户端发送298 bytes数据，下⼀轮客户端可以要求服务器从3179开始发送客户端向服务器确认我已经收到你前3179个数据包，这3179个数据包对于服务器来说是分为三次发送的，但是客户端⼀次进⾏确认仍然是SSL握⼿的信息，客户端向服务器发送93 bytes的数据此时开始传输应⽤层数据啦，客户端向服务器发送93bytes数据，并表⽰下次我从704开始发送，这就是整个过程啦输⼊URL直到收到application data的整个过程就是这样啦，虽然TCP之上不是采⽤常见http协议，⽽是SSL，但是在通信过程中的流量控制及通信双⽅的接收窗⼝很明确以上都是⾃⼰根据OSI模型及各层的作⽤分析得来的，当然也有参考他⼈的分析过程，若有错误欢迎指正啦~