反向代理的一些思考

反向代理的一些思考

前要

在日常部署网站的过程中，我们通常会使用诸如Nginx或者Caddy之类的Web服务器来实现反向代理，将本地一些诸如8080端口反向代理到80和443端口来实现http和https的域名访问

但由于我们日常使用中，通常是直接将本地的容器或者其他服务的端口代理到80端口，很少代理到其他端口，那我们能不能使用其他端口，诸如81端口呢？

默认端口更换

对于Nginx来说，我们需要修改位于 ect/nginx/nginx.conf的配置文件：

找到 server块，修改监听端口

1
2
3
4
5
server {
    listen 8080; # 这里原本的默认端口为80
    server_name example.com;
    # 其他配置...
}

保存配置文件并重启Nginx：

1
sudo systemctl restart nginx

访问

修改端口之后，我们就不能按照原来通过浏览器 输入 http://example.com的方式访问了，因为 http的默认端口是80，如果我们不强行加入端口，浏览器只会按照默认的80端口进行访问

正确的访问方法是通过 http://example.com:8080这样浏览器就会知道你是想通过8080端口进行访问

延时

通常我们代理服务器大多都配置在内网，很少出现异地部署，我其实一直很好奇这种部署方法的具体操作方法以及延时如何，下面是我的一些思考：

首先假设你有两台服务器，一台是A服务器，IP为 192.1.2.3；另一台服务器是B服务器，IP为 172.0.0.3。两台服务器不在同一地点，从A服务器 ping B服务器的延时大概在 50ms左右，用户 ping A服务器的延时在 50ms左右，ping B服务器的延时大概在 10ms左右。我们希望去访问B服务器的某个网络服务。

其中反向代理服务器部署在A服务器中，代理了B服务器的某个端口，我们其网络拓扑图类似于：

此时当我们开始反向代理后，其网络拓扑图变为：

从图中我们不难发现，当我们尝试使用A服务器作为反向代理服务器时，我们所想要访问域名的解析结果应该是指向A服务器，然后再通过A服务器将流量转发到B服务器的

在这个过程中流量就要经过二次转发，所以经过反向代理后的总延时为：20ms+50ms=70ms，要高于直连的 10ms

当然我们部署反向代理服务的时候通常是在同一台机器或者是同一个内网中，这种网络传输的延时很低，基本上可以忽略不记，但是对于这种跨地域的代理，实际影响就很明显了

总结

如果不是什么很奇怪的想法，还是不要采取这种跨地域的反向代理服务，如果你的反向代理服务器和源服务器的通讯要远远好于直接与用户的通讯，那倒确实是一个很不错的想法 （那为什么不上CDN