用户与浏览器交互的过程

本文总阅读量

前记

查阅资料后总结的范围从大到小,用户与浏览器交互的过程。
用户端以浏览器示例。

OSI7层

当浏览器需要访问资源时,浏览器与应用层相关协议(http、htpps)进行交互,并将数据传给表示层进行数据转换再传给传输层(https还需要会话层 TLS、SSL 等协议)
由于http、htpps基于TCP协议,所以需要经历三次握手过程,也就是:
第一个是“连接协定”数据段,用于请求同步(syn)
接下来的数据段确认请求(ack),并在主机之间确定连接参数,同时同步接收方排序
最后一个数据段也是确认通知目标主机,接受了协定且连接已确立
3次握手与4次分手流程图如下:
enter description here
由于从这一层开始提供端到端的服务。措意可以实现流量控制、负载均衡,同时数据段也多了端口、控制字和校验和
传输层之后是网络层,这里主要是通过路由协议进行路由转发,还有访问控制表限制,网络地址转换等。再向下数据链路层主要是 ARP、RARP 协议完成 IP 和 Mac 地址互解析,再向下到最底层物理层基本就是 IEEE 802.X 等协议进行数据比特流转成高低电平的的一些定义等等。下面的这几层已经偏向于网络与路由交换机方面,故不展开。

浏览器与服务器

当输入完url并按下回车时,浏览器与服务器的数据交互就开始了
首先浏览器要通过DNS服务器来查询网址对应的Ip地址,查询顺序如下:
浏览器缓存→系统缓存→路由器缓存→ISP DNS缓存→从根域名服务器递归搜索
浏览器获得ip地址后,就把请求发送给服务器,除了url本身中的资源路径外,在报头中还有写参数
Accept和Accept-Encoding(表明希望收到的数据)、User-Agent(识别浏览器类型的UA)、Connection(用以表明获取后就关闭链接还是保持开启)、Host、Cookie(储存的cookie)
服务器根据请求回复相关数据,如果url中没填写www或者这个服务端对应多个url 服务端会发送301让浏览器重定向到正确的url
服务端根据url请求的路径和参数,从数据库中获取数据并和对应的前端3宝返回给浏览器
浏览器根据服务器回复的数据和前端3宝渲染页面

服务端

服务端由 反向代理服务器、后端服务器、web应用组成。反向代理服务器如Nginx,在拿到请求后,进行一些验证,比如黑名单拦截之类的,然后 Nginx 直接处理静态资源请求,其他请求 Nginx 转发给后端服务器。在python web中后端服务器一般为WSGI,通过 uwsgi 协议通讯,uWSGI 拿到请求,可以进行一些逻辑, 验证黑名单、判断爬虫等,之后根据 wsgi 标准(wsgi说明),把拿到的 environs 参数扔给web应用。web应用以Django为例,Django 根据 wsgi 标准接收请求和 env, 然后开始 start_response ,先跑 Django 相关后台逻辑,Django 拿到请求执行 request middleware 内的相关逻辑,然后路由到相应 view 执行逻辑,出错执行 exception middleware 相关逻辑,接着 response 前执行 response middleware 逻辑,最后通过 wsgi 标准构造 response,再通过 uWSGI 给 Nginx ,Nginx 返回给浏览器。
Django执行流程图如下:
enter description here

查看评论