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

75次阅读

共计 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/…

正文完
代理 前端 跨域
发表至： javascript
2019-07-11
 0
功能性组建和Classes有什么不同？
关于javascript:js插入排序
关于javascript:大白话讲防抖与节流
导航栏固定、锚点平滑滚动