环境: win10, 谷歌浏览器,wireshark2.6.0
电脑通过网线接入网络,IP地址为10.112.228.49
IPV4 DNS地址为10.3.9.4或者10.3.9.5,此外,浏览器所在子网的网络号为前16 bytes, 即10.3
待请求的URL: www.jianshu.com(这里其实是https://www.jianshu.com/,表示用https协议传输,HTTPS实际上应用了Netscape的安全套接字层(SSL)作为HTTP应用层的子层。因此,这里的数据包通信与http协议有一点不一样)
1. 打开wireshark,选择下图中的网卡。并且在谷歌浏览器的无痕窗口中输入www.jianshu.com。

红线上的网卡对应的IP地址为10.112.228.49
2. 数据包分析

第100个数据包表示本机向DNS服务器发送DNS请求,请求www.jianshu.com的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协议传输,表明域名www.jianshu.com对应的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 = 1

SSL握手

客户端向服务器发送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模型及各层的作用分析得来的,当然也有参考他人的分析过程,若有错误欢迎指正啦~
参考:
https://blog.csdn.net/ITermeng/article/details/77833356
https://blog.csdn.net/wdscq1234/article/details/52444277
网友评论