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

1、先从网络模型的层面：

　　cilent与server通过http协议通讯，http协议属于应用层协议，http基于tcp协议，所以cilent与server主要通过socket进行通讯；tcp属于运输层协议，如果走https还需要会话层TLS、SSL等协议；同时还需要DNS域名解析等；传输层之下网络层，这里主要是路由协议OSPF、RIP等进行路由转发之类的。再向下数据链路层主要是ARP、RARP协议完成IP和MAC地址的互解析，再向下到最底层物理层基本就是IEEE802.X等协议进行数据比特流转成高低电瓶的一些定义等等。

　　http：协议无状态，基于TCP，属于应用层协议

　　DNS：域名解析系统，通过域名或主机名，最终得到该域名或主机名对应的IP地址的过程叫做域名解析(RDNS就是将IP地址反向查询为域名，成为反向域名解析)，DNS协议运行在UDP协议之上，使用端口号53。DNS会有一些策略将静态的东西直接返回给浏览器，只有动态部分才继续向后面传递。

　　SSL：安全套接字协议、TSL：安全传输层协议，在传输层上给非安全的应用层协议提供加密保护，比如https

　　TCP：传输控制协议，属于传输层协议

　　OSPF：优先开放最短路径。基于链路状态的自治内部路由协议，进行路由转发。

　　ARP：地址解析协议，工作在数据链路层，ARP解决的是同一个局域网上的主机或者路由器的IP地址映射问题。

　　RARP：反向地址解析协议，负责将局域网中主机的物理地址转换为Ip地址。

　　当浏览器发出请求，首先进行数据封包，然后数据链路层解析IP与MAC地址的映射，查找ARP表，然后找到对应目标路由器，路由器收到数据报，通过DNS协议解析的目标IP，进行路由寻址，到达传输层，传输层进行TCP三次握手、四次挥手建立和断开连接，再进入应用层，http进行数据交换。

　　DNS域名解析如下(本机向本地域名使用递归查询，本地域名向根域名使用迭代查询)：

2、应用层方面

　　数据交换主要通过http/https协议。http协议是无状态协议，这里可以谈一下post和get两种方式：

　　　　get方式：是以实体的方式得到有请求URL所指定资源的信息，如果请求URL只是一个数据产生的过程，那么最终要在响应实体中返回的是处理过程的结果所指向的资源，而不是处理过程的描述。

　　　　post方式：用来向目的服务器发出请求，要求接受被附在请求后的实体，并把它当做请求队列中请求URI所指定资源的附加新子项，post被设计成统一的方法实现下列功能：

　　　　　　　　① 对象有资源的解释；

　　　　　　　　② 向电子公告栏、新闻组、邮件列表或类似讨论组发信息；

　　　　　　　　③ 提交数据块

　　　　　　　　④ 通过附加操作来扩充数据库

　　　　get是向服务器发索取数据的一种请求，而psot是向服务器提交数据的一种请求，要提交的数据位于信息头后面的实体中

　　　　post和get的区别有：

　　　　　　　　① 安全性问题；在客户端，get方式再通过url提交数据，数据在url中可以看到；post方式，数据放置在html的header内提交。

　　　　　　　　② get方式提交数据最多只有1024字节，而post方式则没有限制。

　　　　　　　　③ 安全的和幂等的。所谓安全的意味着该操作用于获取信息而非修改信息。幂等的意味着对同一 URL 的多个请求应该返回同样的结果。完整的定义并不像看起来那样严格。换句话说，GET 请求一般不应产生副作用。从根本上讲，其目标是当用户打开一个链接时，她可以确信从自身的角度来看没有改变资源。比如，新闻站点的头版不断更新。虽然第二次请求会返回不同的一批新闻，该操作仍然被认为是安全的和幂等的，因为它总是返回当前的新闻。反之亦然。POST 请求就不那么轻松了。POST 表示可能改变服务器上的资源的请求。仍然以新闻站点为例，读者对文章的注解应该通过 POST 请求实现，因为在注解提交之后站点已经不同了（比方说文章下面出现一条注解）。

　　通过https进行数据交换，一般通过post方式，https本身并非协议，而是标准的HTTP协议架在SSL/TLS协议之上的一种结构。由于HTTP协议是基于TCP/IP进行通讯的，所以HTTPS必须暴露IP和端口，这部分不加密。

　　https在传输数据前需要客户端与服务器进行一次握手，在握手的过程中将确立双方加密传输数据的密码信息。握手的时候一般使用非对称加密和哈希算法，握手后数据传输才用对称加密。握手过程如下：

　　　　1、浏览器将自己支持的一套加密规则发送给网站。

　　　　2、网站从中选出一组加密算法和hash算法，并将自己的身份信息用证书的形式发送给浏览器。证书里面包括了网站地址，加密公约，以及证书的颁发机构等信息。

　　　　3、获得网站证书后浏览器要做以下工作：

　　　　　　　　① 验证证书的合法性(颁发证书机构是否合法、证书是否过期、证书中地址是否与正在访问的地址一致)：如果证书受信任，则浏览器里面会显示一个小锁头，否则会给出证书不受信任的提示。

　　　　　　　　② 如何证书受信任，或者用户接受了不受信任的证书，浏览器会生成一串随机密码，用最开始约定好的hash方式，把握手消息hash值，然后用证书中提供的公钥加密“握手消息+握手消息hash值”发送给服务器。

　　　　　　　　③ 服务端拿到客户端传来密码，用自己的私钥来解密握手消息取出随机密码，再用随机数密码解密握手消息与hash值，并与传过来的hash值做对比确认是否一致。然后服务端自己也生成一个随机密码加密一段握手消息(握手消息+握手消息hash值)给客户端。

　　　　　　　　④ 客户端用随机数解密并计算握手消息hash，如果与服务器发出hash一致，此时握手过程结束，之后的所有通信数据将有之前浏览器和服务器生成的随机码生成的一个新的随机密码并利用对称加密算法进行加密。利用客户端和服务端的随机码来生成数据传输的随机码是为了防止写死的假随机码带来的安全隐患，使用对称加密是因为对称加密的加密加密过程比非对称快得多。

　　　　　　　　非对称加密算法：RSA DSA DSS

　　　　　　　　对称加密：AES RC4 3DES HASH

　　　　　　　　算法：MD5 SHA1 SHA256

3、服务器方面(Ngin为例)

　　　 server 这边 Nginx 拿到请求，进行一些验证，比如黑名单拦截之类的，然后 Nginx 直接处理静态资源请求，其他请求 Nginx 转发给后端服务器，这里我用 uWSGI, 他们之间通过 uwsgi 协议通讯，uWSGI 拿到请求，可以进行一些逻辑， 验证黑名单、判断爬虫等，根据 wsgi 标准，把拿到的 environs 参数扔给 Django ，Django 根据 wsgi 标准接收请求和 env， 然后开始 startresponse ，先跑 Django 相关后台逻辑，Django 拿到请求执行 request middleware 内的相关逻辑，然后路由到相应 view 执行逻辑，出错执行 exception middleware 相关逻辑，接着 response 前执行 response middleware 逻辑，最后通过 wsgi 标准构造 response， 拿到需要返回的东西，设置一些 headers，或者 cookies 之类的，最后 finishresponse 返回，再通过 uWSGI 给 Nginx ，Nginx 返回给浏览器。　　 　　

 

参考文章：

https://blog.csdn.net/w_rcss/article/details/79890294

https://www.cnblogs.com/xiexj/p/6439775.html

https://www.cnblogs.com/yifugui/p/8430707.html