Proxy Server | 正向代理与反向代理
看到这里的同学应该对「代理」并不陌生。无论是特别的上网技能还是 Nginx 映射本地端口,都离不开代理的特效。
这次,让我们再一次看看:代理,究竟是如何运作的。并重点介绍下可能更陌生一点的「反向代理」,我们可以用反向代理干什么。
What’s 「Proxy」 ?
无论正向代理还是反向代理,都是「代理」(废话?)
代理就像一个中转站,服务端与客户端之间的交流交给代理在中间代理。客户端想访问服务端,并不直接向服务端发出请求,而是向代理发出,然后让代理转交给服务端;同样的,服务端返回数据,并不是直接发回给客户端,而是发给代理,再让代理交还给客户端。所有客户端和服务端之间的流量都会由代理来转发。
好像把事情变麻烦了?不急,它自有用处。
Forward Proxy | 正向代理
正向代理工作原理
在正向代理时,代理服务器会先和客户端(Client)建立连接,然后客户端将某些特定请求或全部网络请求发给代理服务器,代理服务器再拿着请求跑去送给对应的服务端(Server)。同样的,服务端回应这个请求的时候也是先发给代理服务器(毕竟表面上这个请求是代理服务器发出的),然后代理服务器再把回应送回给客户端。
![](https://cdn.jsdelivr.net/gh/ichralpha/imgbag/20200202184928.jpg)
优势
从上面介绍的正向代理工作原理来看,代理服务器负责代替客户端发出和接收网络请求,所以表面上好像是代理客户端在发出请求(实际上貌似也是) ,这样给真实的客户端披上一层外套。
不难发现,正向代理可以:
- 突破访问限制(解锁),比如某些限制了地区使用的资源,我可以用一个当地的代理,让它代理我的流量,骗过服务端。
- 屏蔽广告,代理服务器可以判断返回的内容,如果是不受欢迎的广告或追踪代码,代理服务器就把它拦下来,不发给服务端。
- 匿名,可能有很多同学都在使用一个代理,服务端无从知道真实的请求是谁发出的,只知道是由代理转发的。从而保障了一定的匿名性。
Reverse Proxy | 反向代理
反向代理工作原理
那反向代理又是如何工作的呢?这次代理是替服务端(Server)工作了。
服务端只对外公开代理的地址,所有发送给服务端的请求都会先到代理那里,然后让代理再根据请求分发给相应的服务端;回应的时候也是类似。
![](https://cdn.jsdelivr.net/gh/ichralpha/imgbag/20200202184929.jpg)
优势
为什么需要这样的一步呢?其实许多服务器并不是十分顽强,收到过多的请求甚至可能宕机,更不用说要是被攻击了。而套上这一层反向代理,代理服务器可以将请求均衡地分配给服务器组,防止过多请求集中在一台或者几台服务器上,使其负载过大影响服务,这就叫「负载均衡」。同样地,遇到异常流量,代理可以直接拦截下来,而且代理还可以隐藏服务端的真实地址,这都起到了保护服务端的作用。
反向代理不仅可以保护服务器,甚至还可以加速访问!比如代理服务器可以将一些静态资源缓存下来,如果遇到请求,就不用向服务端发送,直接返回资源,更有利于让服务端将算力、带宽集中在加载重要的地方。
这里就不得不提到 CDN 了。CDN 的全称是内容分发网络 (Content Delivery Network 或 Content Distribution Network) ,可以将资源缓存在多台服务器上,访问的时候从最近的服务器中获取,提供高性能的传递且降低骨干网负载。而 CDN 大多也是基于 Nginx 或者 Nginx + SNI 反向代理实现的,所以你也可以将域名指向 CDN 隐藏真实地址。
实践出真知
端口映射
我在自己的 VPS 上 搭建 Jupyter Notebook 实现 Web 端编写运行 Python 代码。
我配置 Jupyter Notebook 是运行在 localhost:35767
上的。目前我已经将 jupyter.domain.com
解析到该 VPS 地址上了,而从公网访问 VPS 地址都是直接发送给 Nginx 代理上的。所以我们要合理配置 Nginx 使其能够让域名转发到对应服务的端口。
打开你的 Nginx 主配置文件(一般在 /etc/nginx/nginx.conf
,如果你也是使用宝塔的快速安装,那么会在 /www/server/nginx/conf/nginx.conf
)
首先我们定义 upstream 内容:
uptream jupyter {
server 127.0.0.1:35767;
}
这样就规定了名为 jupyter
的服务是在本机地址的 35767 端口上运行的,如果访问这个服务就定位过去。之后请求就可以以 http(s)://jupyter
代表 jupyter
的服务端地址,也就是 127.0.0.1:35767
。
然后我们监听 http/https 的请求,分别在 80/443 端口。
server {
listen 80;
listen 443 ssl;
server_name jupyter.domain.com; # 对应的域名
# https...ssl...
location / {
proxy_pass http://jupyter; # 转发请求
}
}
这样就实现了让 juypter.domain.com
的请求跳到 juypter
的服务地址,而之前我们已经配置好了该服务地址。
负载均衡
端口映射并不能真正体现 upstream 的强大,而负载均衡就不一样了。比如我想将 aria2c.domain.com
请求平均的分配到 6800 和 6999 这两个端口上。
首先定义 upstream :
upstream aria2c {
server 127.0.0.1:6800;
server 127.0.0.1:6999;
}
之后就只需要监听端口,判断域名是否匹配,然后转发到 http://aria2c
即可。
默认两个端口是同级的(权重为 1),你还可以为每个端口设定一个权重,或者根据 IP 分配,根据响应时间分配,等等。
后
看,正向代理拓展了客户端上网的姿势,反向代理使服务端更加强大。
但其实,代理能做到的远不止这些,目前已经有了许多玩法。无声无息中为大家提供便利。
限制代理能力的,或许只有人们的脑洞罢了。
评论