深入理解 http 反向代理

我的理解：

http正向代理

浏览器需要设置访问哪个服务器

流程：浏览器发起请求到中间的代理服务器，代理服务器收到浏览器的请求后，像正式服务器发送请求，正式服务器把响应结果发送给代理服务器，代理服务器把正式服务器的响应结果发送给浏览器。

反向代理

Nginx是静态资源服务器，动态生成需要 Nginx 将主页的请求转发给一个所谓的 php-fpm 网关（ php-fpm 网关基本可以看作是个 php 的 web 服务器, 不过严格来说它用的协议不是 http, 而是一种内部简化的 fastcgi 协议.）。请求被转发到内部一个在 9000 端口上监听的 php 应用服务器.

示意图：

站在整个体系设计者的角度去看, Nginx内部把它代理给了另一个内部的 php 应用服务器, 内部的 php 应用服务器才是最终的响应生成者.

在整个体系里面, Nginx 的角色就是一个"反向代理"服务器, 浏览器被代理了, 但它无从知道自己是否被代理了, 这一切对它而言是透明的, 反正它自己是没有主动走(正向)代理的.

当然了, 你现在知道了我内部的配置, 如果直接访问 xiaogd.net:9000, 那就是真正的"直接访问"了, 那就绕过了 Nginx.

不过需要说明的一点时, 直接访问是访问不通的, 因为 9000 端口并没有对外放开. 但是在内部是可以访问到的, 比如这样尝试用 wget 去访问:

wget localhost:9000

需要说明的一点是, 用 wget 这样去获取响应还是会报错, 因为 wget 使用的是 http 协议, php 的 cgi 网关实际使用的是 fastcgi 协议, 是一个比 http 更为简化的协议, 作为内部通讯更加高效, 不过 wget 不支持这个协议, 但 Nginx 能理解这个协议, 整个过程是这样的:

browser -- [http] --> Nginx -- [fastcgi] --> php-fpm

严格来说, 不完全是 http 代理, 内部的反向代理实际用的是 fastcgi 网关协议, 不过这个原理还是一样的, 如果内部用一个比如 tomcat 来响应, 那么全程就都可以是 http 协议.

browser -- [http] --> Nginx -- [http] --> tomcat

反向代理的原因 负载均衡

一个进程（处理有限量的请求）对应一个端口，请求多了，一个进程处理不过来，需要发起一个进程，并且要开放一个端口，访问链接就不好处理了

在这种情况下, 反向代理的好处就体现出来了, 具体的操作是这样的, 让 Nginx 作为一个前置的反向代理, 监听在 80 端口上; 而第一个 tomcat 则躲到幕后, 同时它也不再监听 80 端口(需要让给 Nginx), 而改为监听一个其它没有被使用的端口, 比如 8081, 然后让 Nginx 转发请求给它处理.

如果同时涌入了很多请求, Nginx 会把一半的请求交给 8080 端口上的 tomcat, 另一半的请求交给 8081 端口上的 tomcat, 如下图所示:

作者：肖国栋的i自留地

链接：https://juejin.cn/post/6958987684383555592

来源：稀土掘金

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。