从前端角度用正向反向代理解决开发时的跨域问题

7次阅读

共计 4882 个字符,预计需要花费 13 分钟才能阅读完成。

前言

这篇文章的初衷是结合我看到其他前辈们的文章所总结的一些心得,可能不会很全面,不过大概的知识流程应该还是能传达给大家的。

内容大概

  • 浏览器输入 url 的时候,到回来显示整个大致流程
  • 正向代理,反向代理
  • 前端处理跨域

浏览器输入 url 之后,到页面显示回来的大致过程(前端角度)

举例:比如我准备在浏览器输入 https://baidu.com

过程分析:
第一步:获取 IP 地址

(1)在浏览器输入地址之后,注意,咱们这个baidu 是域名,不是 IP 地址;

(2)这个时候浏览器会去找这个域名对应的是哪个 IP 地址,一般来说,会先找我们电脑 本地硬盘的 hosts 文件,看一下有没有相关规则;

(3)如果本地 hosts 文件没有找到 IP 地址,那这个时候就去会去 DNS 服务器 找, 并返回 IP 地址;

第二步:发请求,建立 TCP 连接(三次握手)
(1)这里的细节我不过多说,我们只需要知道,上一步获取到 IP 地址之后,客户端开始向这个 IP 地址发送请求前,会先进行TCP 连接

三次握手是指这个连接的过程中:
1)客户端先发送一次报文给服务器;
2)服务端收到,再发一个给客户端;
3)客户端接受到,再发一次报文,同时也把这次的 HTTP 请求一起发过去

(2)经过握手之后,TCP 连接成功,服务端这时也接受到了请求(在最后一次握手 ),接着处理之后把响应发回给客户端的同时,服务端会先 单方面关闭 TCP 连接

(3)客户端接受到请求数据,也把 TCP 连接关闭,这时才算 完成一次请求

小结论:从这里我们就可以知道,为什么要说前端减少 HTTP 请求会对性能有优化作用,就是因为你每一个请求它都要跑上面的过程,握手耗时

第三步:浏览器拿到 html 文件,开始渲染,并且发送请求获取嵌入在 HTML 中的资源(如 CSS、JS、图片、音频、视频等)
(这里后面再补充)

代理

1、在讲之前先说一下最终的结论(个人理解,可能有误)

  • 正向代理:知道真正的请求地址,在向这个地址发送请求的时候,被代理服务器拦截,然后帮你去请求这个地址,最后把请求结果从真实服务器拿回来,再返回给你;
  • 反向代理:不知道真正的请求地址 知道一个假的 ,在你请求这个假地址(这个假地址就是在代理配置的,当然也把正确的地址配置进去,通常是在服务端配置这个代理服务器,所以说这个真实地址对客户端是透明的) 的时候,被代理服务器拦截,然后步骤跟上面一样;

2、讲解
(1)正向代理
说明:
正向代理 (forward) 是一个位于客户端【用户 A】和原始服务器(origin server)【服务器 B】之间的服务器【代理服务器 Z】,为了从原始服务器取得内容,用户 A 向代理服务器 Z 发送一个请求并指定目标(服务器 B),然后代理服务器 Z 向服务器 B 转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理。

通俗大白话:
正向代理 需要在客户端设置 ,在这个过程中, 真正的服务器 B 并不知道到底是哪个客户端发起的请求,因为它所有的请求都是来自 代理服务器 Z ,所以说,在正向代理中,我们会说此时客户端是透明的。

正向代理用途:
1)科学上网;
2)对客户端访问授权,上网进行认证
3)可以做缓存,加速访问资源

(2)反向代理
说明:
反向代理正好与正向代理相反,对于客户端而言代理服务器就像是原始服务器,并且客户端不需要进行任何特别的设置。客户端向反向代理的命名空间 (name-space) 中的内容发送普通请求,接着反向代理将判断向何处 (原始服务器) 转交请求,并将获得的内容返回给客户端。

通俗大白话:
反向代理 不需要在客户端设置,在这个过程,客户端只需要请求这个代理服务器,这个代理服务器会自动根据相关设置去请求对应的真正的服务器,所以说,在反向代理中,我们会说此时服务端是透明的。

反向代理用途:
1)负载均衡,减轻服务器压力(目前只知道这个);

(3)小结论
是不是觉得有点奇怪?两个都是请求代理服务器,都是由代理服务器去请求真正的服务器?到底有什么不同?请看我最开始上面说的结论。

(4)图解
借用知乎两张图来表达:https://www.zhihu.com/questio…

跨域(重点来了)

我前面说了这么多,什么敲入地址,代理啊,都是为了讲一下在我们平时的开发中,怎么解决跨域这个问题。

(1)概念
跨域是由浏览器同源策略引起的,是指页面请求的接口地址,必须与页面 url 地址处于同域上(即域名,端口,协议相同)。这是为了防止某域名下的接口被其他域名下的网页非法调用,是浏览器对 JavaScript 施加的安全限制。

注意:通过后台调接口是不会有跨域问题的,而是会出现这个接口设置了不让其他服务器调用的其他问题

例子:从 http://www.lizi.com/home/index.html 向以下地址发送请求 
1. http://www.lizi.com/home/detail.html 成功,路径不同 
2. http://www.lizi.com/description/detail.html 成功,路径不同 
3. https://www.lizi.com/home/list.html 失败,协议不同(http 和 https)4. http://www.lizi.com:8848/home/manange.html 失败,端口不同(默认 80 和 8848)5. http://mobile.lizi.com/home/secret.html 失败,域名不同(www 和 mobile)

(2)怎么解决呢
虽然浏览器有限制,但是 HTML 中有两个属性是不受限制的,那就是src 和 href 属性

<img src="http://www.lizi.com/xxx.jpeg"></script>
<link rel="stylesheet" href="http://www.lizi.com/css/reset.css"> 
<script src="https://cdn.bootcss.com/jquery/3.4.0/jquery.min.js"></script>
<link href="https://cdn.bootcss.com/twitter-bootstrap/4.3.1/css/bootstrap.min.css" rel="stylesheet">

是不是很熟悉?我们平时开发中上面代码肯定经常用。根据这个特性,前端大佬们想到了一个解决跨域的方式 —JSONP
2.1)JSONP
先说结论:这个方法是 前后端要互相配合,比如约定那个函数的名字叫啥之类

// 这个是请求页面
// 里面有一个 script 标签,它的 src 是一个请求地址, 在地址后面拼接了一个参数 callback,值为 sendStudent
// 页面也写了一个 sendStudent 的函数,跟传过去的 callback 值是对应的
// 当这个请求成功返回来之后,咱们页面这个 sendStudent 就会自动触发
// 当然触发的时机,是服务端那边执行了  sendStudent('数据数据')  这段代码, 这个写法就是咱们 JS 触发函数的写法,只是现在把这段代码放在了服务端
<!doctype html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>JSONP</title>
  <script src="http://www.baidu.com/api/student?callback=sendStudent"></script>
</head>
<body>
<script>
    function sendStudent(res){console.log('这里就是服务端返回来的数据',res);
    }
</script>
</body>
</html>

// 假装这里是后台代码
xxxx
xxx
xx
sendStudent({user:'我是数据'})

2.2)CORS
先说结论:这个只需要 后端设置 就行了,前端不用

这个方法具体操作是设置接口的响应头,服务器设置 HTTP 响应头中 Access-Control-Allow-Origin 值,解除跨域限制。
不细说,到后面我再贴相关的参考链接(因为我也不懂)

2.3)代理
在一般的开发过程中,上面两种方法在使用的时候都是需要后端配合的,而下面说的代理,是可以实现只需要在前端配置即可。
2.3.1)正向代理
例子:比如开发 vue 项目时,假设出现这种情况
这个是页面

这个是接口(我随便用 node 写一个接口)

在这个 vue 页面中,我开的项目端口是 http://127.0.0.1:8070,而我请求的接口地址是 http://127.0.0.1:2019/student,
端口不同,所以肯定会存在跨域,咱们验证一下

这句话果然出现了,那行,接下来我们用正向代理的方式解决

在 vue 的 webpakc 配置中,我们可以在下面这个地方配置代理


proxyTable: {
  '/api':{
     target: 'http://127.0.0.1:2019',// 这里是真正的接口, 写到端口就行,不要把资源也带上去,比如 /student
     changeOrigin:true,
     pathRewrite: {'^/api':''}
   }
}

设置好之后,咱们看一下现在 vue 页面的接口怎么写

我把刚才 http://127.0.0.1:2019/student 改成了 /api/student,这个 /api 就是咱们在 proxyTable 配置的别名,现在来刷新一下页面

我们看到,newwork 那里显示的是我们这个 8070 端口号的请求,协议,域名,端口都一样所以肯定是不会报跨域错误,
然后请求经过配置的那个代理,把真正的请求转发到 http://127.0.0.1:2019/student,数据成功返回。

2.3.2)反向代理
网上好多教程都是说用 nginx,那我们也用这个演示一下吧。

这里就不说怎么下载这个过程了,自己去百度一下,当我们下载好了之后,找到 conf 文件夹下面的 nginx.conf 文件,然后编辑

说明一下

  1. nginx 启动在 8999 的端口上;
  2. 访问的时候,配置读取我 vue 项目的端口,也就是 8070 端口;
  3. 设置别名,跟上面的正向代理一样,地址指向真正的接口地址;

配置好,启动

这个时候,跟正向那个访问的方式不一样,咱们要在浏览器打开这个地址 http://127.0.0.1:8999,而不是 8070 那个端口。
因为我们已经配置好了,所以它会访问到我们 8070 端口的页面

这个时候看一下接口访问,按照理想情况,应该也跟正向代理一样可以成功访问接口并返回了,但是,我们却看到这样的情况

接口报 404 了????
我自己也不知道是什么问题,感觉 nginx 并没有向正向代理一样,自动把这个地址真确匹配上,我们回头看看上面那个正向代理的请求地址

请求:http://127.0.0.1:8070/api/student
实际:http://127.0.0.1:2019/student

虽然端口跟资源都是不一样,但是正向代理帮我们把端口跟路径都处理好,但是这个反向代理好像不太一样,我先改一下然后再说说

这里可以看到,我把本来接口的 /student 改成了 /reapi/student,我们现在再访问一下

额,这时候发现可以了,我们对比一下接口

请求:http://127.0.0.1:8999/reapi/student
实际:http://127.0.0.1:2019/reapi/student

可能是我配置的 nginx 有问题,它只帮我替换了端口,没有帮我像正向代理一样把资源地址也替换好,导致我要去改接口的地址。

文章到此暂告一段落,后面如果发现哪里漏了或写错我会补充上,希望各位大佬多多见谅。

最后特此鸣谢各种大神的文章
代理:
(1)https://www.cnblogs.com/nul1/…
(2)https://www.cnblogs.com/xuyat…
(3)https://www.cnblogs.com/softi…
浏览器:
(1)https://www.cnblogs.com/gaoxi…
跨域:
(1)https://zhuanlan.zhihu.com/p/…

正文完
 0