Wireshark 抓包分析-使用网址、域名访问 Web 服务器后面发生了什么?

计算机网络 专栏收录该内容
17 篇文章 0 订阅

使用 IP 地址访问 Web 服务器

首先打开 Wireshark,选择 ”HTTP TCP port(80)“ 过滤器,再鼠标双击 ”Npcap loopback A dapter“,开始抓取本机 127.0.0.1 地址上的网络数据。

接着在 Chrome 浏览器地址栏输入”http://127.0.0.1/“,再按下回车键,等欢迎页面显示出来后 Wireshark 就会有铺获的数据包。如下:
在这里插入图片描述

抓包分析

在 Wireshark 里可以看到,一共抓取 11 个包,耗时约 0.65 秒,接着看按下回车后数据传输的全过程:

HTTP 协议是依靠 TCP/IP 实现数据的可靠传输。所以浏览器要用 HTTP 协议收发数据,首先就是建立 TCP 连接

在地址栏里直接输入了IP地址“127.0.0.1”,Web服务器的默认端口是80,浏览器就依照 TCP 协议的规范,使用 ”三次握手“ 建立与 Web 服务器的连接。对应到 Wireshark 里,就是最开始的三个包,浏览器的端口是 52085,服务器使用的端口是 80,经过 SYN、SYN/ACK,ACK 的三个包之后,浏览器与服务器的 TCP 连接就完成

在这里插入图片描述
有了可靠的 TCP 连接通道后,HTTP协议就可以开始工作。于是,浏览器按照HTTP协议规定的格式,通过 TCP 发送了一个“GET / HTTP/1.1”请求报文,也就是Wireshark里的第四个包

在这里插入图片描述
收到请求包后,Web 服务器回复了第五个包,在TCP协议层面确认:“刚才的报文我已经收到了”,不过这个 TCP 包 HTTP 协议是看不见的

在这里插入图片描述
回复收到后Web服务器就在内部处理这个请求。同样也是依据HTTP协议的规定,解析报文,看看浏览器发送这个请求想要干什么,原来是要求获取根目录下的默认文件,好吧,那我就从磁盘上把那个文件全读出来,再拼成符合 HTTP 格式的报文,发回去吧。这就是Wireshark里的第六个包“HTTP/1.1 200 OK”,底层走的还是TCP协议

在这里插入图片描述
同样的,浏览器也要给服务器回复一个 TCP 的 ACK 确认,“你的响应报文收到了,多谢”,即第七个包。但里面是什么呢?所以也要解析报文。一看,服务器给我的是个HTML文件,好,那我就调用排版引擎、JavaScript引擎等等处理一下,然后在浏览器窗口里展现出了欢迎页面。

在这里插入图片描述
这之后还有两个来回,共四个包,是浏览器自动请求了作为网站图标的“favicon.ico”文件,与我们输入的网址无关。但因为我们的实验环境没有这个文件,所以服务器在硬盘上找不到,返回了一个“404 Not Found”

在这里插入图片描述
至此,“键入网址再按下回车”的全过程就结束了。详细过程可以看下面的交互图,但图里TCP关闭连接的“四次挥手”在抓包里没有出现,因为HTTP/1.1长连接特性,默认不会立即关闭连接
在这里插入图片描述

使用域名访问 Web 服务器

把地址栏的输入改成“http://www.chrono.com”,重复Wireshark抓包过程,会发现,好像没有什么不同,浏览器上同样显示出了欢迎界面,抓到的包也同样是11个:先是三次握手,然后是两次HTTP传输。

那么浏览器是如何从网址里知道“www.chrono.com”的IP是“127.0.0.1”?

当发现网址不是数字形式的 IP ,那就肯定是域名了,于是就会发起域名解析动作,通过访问一系列的域名解析服务器,试图把这个域名翻译成 TCP/IP 协议里的IP地址

不过因为域名解析的全过程实在是太复杂了,如果每一个域名都要大费周折地去网上查一下,那我们上网肯定会慢得受不了。所以,在域名解析的过程中会有多级的缓存

浏览器首先看一下自己的缓存,如果没有就向操作系统的缓存要,还没有就检查本机域名解析文件 hosts,也就是 “C:\WINDOWS\system32\drivers\etc\hosts”。刚好,里面有一行映射关系“127.0.0.1 www.chrono.com”,于是浏览器就知道了域名对应的IP地址,就可以愉快地建立TCP连接发送HTTP请求了

我把这个过程如下图,但省略了TCP/IP协议的交互部分,里面的浏览器多出了一个访问hosts文件的动作,也就是本机的DNS解析。
在这里插入图片描述

网络世界

真实的互联网世界要比这两个场景要复杂的多,用下面的这张图来做一个详细的说明。
在这里插入图片描述
如果用的是电脑台式机,那么可能会使用带水晶头的双绞线连上网口,由交换机接入固定网络。如果用的是手机、平板电脑,可能会通过蜂窝网络、WiFi,由电信基站、无线热点接入移动网络

接入网络的同时,网络运行商会给你的设备分配一个IP地址,这个地址可能是静态分配的,也可能是动态分配的。静态IP就始终不变,而动态IP可能你下次上网就变了

假设你要访问的是Apple网站,显然你是不知道它的真实 IP 地址的,在浏览器里只能使用域名“www.apple.com”访问,那么接下来要做的必然是域名解析。这就要用DNS协议开始从操作系统、本地DNS、根DNS、顶级DNS、权威DNS的层层解析,当然这中间有缓存,可能不会费太多时间就能拿到结果

另外,互联网上还有另外一个重要角色CDN,它也会在DNS的解析过程中“插上一脚”。DNS解析可能会给出CDN服务器的IP地址,这样你拿到的就会是CDN服务器而不是目标网站的实际地址

因为CDN会缓存网站的大部分资源,比如图片、CSS样式表,所以有的HTTP请求就不需要再发到Apple,CDN就可以直接响应你的请求,把数据发给你

由PHP、Java等后台服务动态生成的页面属于“动态资源”,CDN无法缓存,只能从目标网站获取。于是你发出的HTTP请求就要开始在互联网上的“漫长跋涉”,经过无数的路由器、网关、代理,最后到达目的地

目标网站的服务器对外表现的是一个IP地址,但为了能够扛住高并发,在内部也是一套复杂的架构。通常在入口是负载均衡设备,例如四层的LVS或者七层的Nginx,在后面是许多的服务器,构成一个更强更稳定的集群

负载均衡设备会先访问系统里的缓存服务器,通常有memory级缓存Redis和disk级缓存Varnish,它们的作用与CDN类似,不过是工作在内部网络里,把最频繁访问的数据缓存几秒钟或几分钟,减轻后端应用服务器的压力

如果缓存服务器里也没有,那么负载均衡设备就要把请求转发给应用服务器了。这里就是各种开发框架大显神通的地方了,例如Java的Tomcat/Netty/Jetty,Python的Django,还有PHP、Node.js、Golang等。它们又会再访问后面的MySQL、PostgreSQL、MongoDB等数据库服务,实现用户登录、商品查询、购物下单、扣款支付等业务操作,然后把执行的结果返回给负载均衡设备,同时也可能给缓存服务器里也放一份

应用服务器的输出到了负载均衡设备这里,请求的处理就算是完成了,就要按照原路再走回去,还是要经过许多的路由器、网关、代理。如果这个资源允许缓存,那么经过CDN的时候它也会做缓存,这样下次同样的请求就不会到达源站了。

最后网站的响应数据回到了你的设备,它可能是HTML、JSON、图片或者其他格式的数据,需要由浏览器解析处理才能显示出来,如果数据里面还有超链接,指向别的资源,那么就又要重走一遍整个流程,直到所有的资源都下载完

小结

浏览器访问服务器 HTTP 请求过程

  • 浏览器从地址栏的输入中获取服务器的 IP 地址和端口号
  • 浏览器用 TCP 的三次握手与服务器建立连接
  • 浏览器向服务器发送拼好的报文
  • 服务器收到报文后处理请求,同样拼好报文再发给浏览器
  • 浏览器解析报文,渲染出页面

EOF
《透视 HTTP》学习笔记

  • 1
    点赞
  • 0
    评论
  • 22
    收藏
  • 打赏
    打赏
  • 扫一扫,分享海报

©️2022 CSDN 皮肤主题:编程工作室 设计师:CSDN官方博客 返回首页

打赏作者

@另维吖

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值