浏览器的一个请求从发送到返回都经历了什么

我大概讲下我的答案:

1、先从网络模型层面:

client (浏览器)与 server 通过 http 协议通讯,http 协议属于应用层协议,http 基于 tcp 协议,所以 client 与 server 主要通过 socket 进行通讯;

而 tcp 属于传输层协议、如果走 https 还需要会话层 TLS、SSL 等协议; 传输层之下网络层,这里主要是路由协议 OSPF 等进行路由转发之类的。再向下数据链路层主要是 ARP、RARP 协议完成 IP 和 Mac 地址互解析,再向下到最底层物理层基本就是 IEEE 802.X 等协议进行数据比特流转成高低电平的的一些定义等等;

当浏览器发出请求,首先进行数据封包,然后数据链路层解析 IP 与 mac 地址的映射,然后上层网路层进行路由查表路由,通过应用层 DNS 协议得到目标地址对应的 IP ,在这里进行 n 跳的路由寻路;而传输层 tcp 协议可以说下比较经典的三次握手、四次分手的过程和状态机,这里放个图可以作为参考:

2、应用层方面:

数据交换主要通过 http 协议, http 协议是无状态协议,这里可以谈一谈 post、get 的区别以及 RESTFul 接口设计,然后可以讲服务器 server 模型 epoll、select 等,接着可以根据实际经验讲下 server 处理流程,比如我: server 这边 Nginx 拿到请求,进行一些验证,比如黑名单拦截之类的,然后 Nginx 直接处理静态资源请求,其他请求 Nginx 转发给后端服务器,这里我用 uWSGI, 他们之间通过 uwsgi 协议通讯,uWSGI 拿到请求,可以进行一些逻辑, 验证黑名单、判断爬虫等,根据 wsgi 标准,把拿到的 environs 参数扔给 Django ,Django 根据 wsgi 标准接收请求和 env, 然后开始 start_response ,先跑 Django 相关后台逻辑,Django 拿到请求执行 request middleware 内的相关逻辑,然后路由到相应 view 执行逻辑,出错执行 exception middleware 相关逻辑,接着 response 前执行 response middleware 逻辑,最后通过 wsgi 标准构造 response, 拿到需要返回的东西,设置一些 headers,或者 cookies 之类的,最后 finish_response 返回,再通过 uWSGI 给 Nginx ,Nginx 返回给浏览器。

原文地址:https://www.cnblogs.com/cuihengyue/p/8985624.html

时间: 2024-11-09 08:40:05

浏览器的一个请求从发送到返回都经历了什么的相关文章

浏览器的一个请求从发送到返回都经历了什么?

浏览器输入url经历图 分析过程: 1.用户输入url,浏览器内部代码将url进行拆分解析 url解析图 2.浏览器首先去找本地的hosts文件,检查在该文件中是否有相应的域名.IP对应关系,如果有,则向其IP地址发送请求,如果没有就会将domain(域)发送给 dns(域名服务器)进行解析(解析如下图),将域名解析成对应的服务器IP地址,发回给浏览器 DNS解析domian过程图 注释:(结合上图看) 浏览器客户端向本地DNS服务器发送一个含有域名www.cnblogs.com的DNS查询报文

浏览器的一个请求从发送到返回经历了什么(转)

1.先从网络模型的层面: cilent与server通过http协议通讯,http协议属于应用层协议,http基于tcp协议,所以cilent与server主要通过socket进行通讯:tcp属于运输层协议,如果走https还需要会话层TLS.SSL等协议:同时还需要DNS域名解析等:传输层之下网络层,这里主要是路由协议OSPF.RIp等进行路由转发之类的.再向下数据链路层主要是ARP.RARP协议完成IP和MAC地址的互解析,再向下到最底层物理层基本就是IEEE802.X等协议进行数据比特流转

.net后台模拟浏览器get/post请求

#region 后台模拟浏览器get/post请求 /// <summary> /// 发送请求方式 /// </summary> /// <param name="url">请求Url</param> /// <param name="para">请求参数</param> /// <param name="method">请求方式GET/POST</par

chrome 浏览器的预提取资源机制导致的一个请求发送两次的问题以及ClientAbortException异常

调查一个 pdf 打印报错: ExceptionConverter: org.apache.catalina.connector.ClientAbortException: java.net.SocketException: Software caused connection abort: socket write error at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:407)

防抖与节流 &amp; 若每个请求必须发送,如何平滑地获取最后一个接口返回的数据

博客地址:https://ainyi.com/79 日常浏览网页中,在进行窗口的 resize.scroll 或者重复点击某按钮发送请求,此时事件处理函数或者接口调用的频率若无限制,则会加重浏览器的负担,界面可能显示有误,服务端也可能出问题,导致用户体验非常糟糕 此时可以采用 debounce(防抖)和 throttle(节流)的方式来减少事件或接口的调用频率,同时又能实现预期效果 防抖:将几次操作合并为一此操作进行.原理是维护一个计时器,规定在 delay 时间后触发函数,但是在 delay

调用webapi 错误:使用 HTTP 谓词 POST 向虚拟目录发送了一个请求,而默认文档是不支持 GET 或 HEAD 以外的 HTTP 谓词的静态文件。的解决方案

第一次调用webapi出错如下: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>IIS 7.5 详细错误 - 4

socket 错误之:OSError: [WinError 10057] 由于套接字没有连接并且(当使用一个 sendto 调用发送数据报套接字时)没有提供地址,发送或接收数据的请求没有被接受。

出错的代码 #server端 import socket import struct sk=socket.socket() sk.bind(('127.0.0.1',8080)) sk.listen() conn,addr=sk.accept() str_len1=struct.unpack('i',conn.recv(4))[0] print(sk.recv(str_len1)) str_len2=struct.unpack('i',conn.recv(4))[0] print(sk.recv

不同的浏览器的刷新行为所发送的头信息是不一样的

3.本地浏览器--代理服务器(squid)--远程服务器(RS) 在这种数据流下,我们来想想工作的原理一下,本地浏览器需要获取一个url上的数据,然后将这个HTTP请求发送给squid,squid将这个HTTP请求变成自己的请求来发送给RS.然后squid获取到数据,并将这个数据返回给本地浏览器.所以我们要明确以下几个重要的概念: 1.对于RS来说,访问RS的是squid:与本地浏览器没有任何直接关联. 2.对于squid来说,HTTP请求如果返回了304,那么squid将从自身获取缓存的数据:

浏览器跨域请求之credentials

-时间起源- 前段时间,需要弄个简单的网站出来,访问远程的api服务. 我是这么做的.首先是在搭建一个nodejs服务来运行前端页面.在我请求登录的时候,能成功返回相应的成功信息.然后,当我再次请求读取别的接口的时候,返回的信息确实提示我尚未登录.此时此刻,我一脸蒙逼.明明我已经登陆了啊.后来偶然得知这是因为浏览器的机制问题. -初步解决- 大概的意思是,默认情况下,标准的跨域请求是不会发送cookie等用户认证凭据的.所以,当你再次访问远程api的时候,cookie是不会被带上的,于是乎,服务