了解正向代理服务器：功能与用途
我们通常使用 NGINX 或 Apache 作为负载均衡器和反向代理服务器，即便外部网络流量需通过这类软件转发，才能抵达内网中的实际服务。存在反向代理的同时，也有正向代理，下面我们来深入探讨它们的功能。
从 OSI 模型到代理服务器
访问互联网服务时，我们通常采用 HTTP 协议，该协议工作在 OSI 模型的第 7 层（应用层）。协议中常见的主机名、路径、查询参数等组件，均属于这一层的内容。HTTP 协议基于 TCP 或 UDP 协议构建，后两者工作在 OSI 模型的第 4 层（传输层），服务访问过程中用到的端口概念也存在于这两种协议中。进一步来说，TCP 和 UDP 都以互联网协议（IP）为基础，IP 协议工作在 OSI 模型的第 3 层（网络层），其中的 IP 地址就相当于互联网的 “门牌号”。
使用 IP 网络访问互联网时，IP 协议负责对目标进行寻址，按规则封装数据包，并将其从源地址在 IP 网络内转发至目的地址。例如，网络流量会从访客的局域网出发，通过互联网服务提供商（ISP）提供的网关设备，接入 ISP 的网络，之后再访问资源提供商的服务。
此时，我们是通过网关访问互联网的。谈及代理服务器，可将其与 IP 网络进行类比。代理服务器就如同网关，起到桥梁作用，协助客户端访问服务。它们本质上工作在 OSI 模型的第 4 层至第 7 层之间，实际上属于 OSI 模型的第 5 层（会话层）。
代理服务器的用途
代理服务器的常见用途如下：
- 内网访问的统一出口。企业通常有特定的信息安全要求，比如访问控制和流量日志记录。随着 HTTPS 等加密流量的普及，将网络流量隐藏在加密协议之下，使得在网络边界难以对其进行记录和审计，增加了数据泄露的风险。代理服务器的存在可作为统一的流量出口，充当中间节点处理流量审计任务。
除了面向人工操作的场景，代理服务也可作为程序化服务访问外网的出口。例如，当服务提供商提供自动通知功能时，需要将流量通过固定出口转发，使用单个固定 IP 地址或一段固定 IP 地址范围。这便于自动通知调用的接收方在防火墙中正确配置白名单，否则双方都可能面临潜在的安全风险。
- 隐藏访客身份。有时互联网用户希望隐藏自己的身份（如 IP 地址），这时透明代理服务器就会发挥作用。客户端首先连接到代理服务器，指定要访问的真实服务地址，然后通过代理服务器使用 HTTPS 协议访问目标服务。代理服务器的存在确保客户端身份不被泄露，而加密协议的使用则保证代理服务器无法在传输过程中窃取数据。
基于 HTTP 的代理
在代理服务器中，我们通常会遇到基于 HTTP 的 HTTP 代理，以及基于二进制协议的 SOCKS 4/5 协议。它们功能类似，但实现方式不同，下面重点介绍基于 HTTP 的代理。
在协议实现的早期阶段，HTTP 流量主要以明文形式传输。这种透明性使得位于客户端和服务端之间的代理服务器能够轻松解析 URL 和请求负载。通过 DNS 解析等过程，代理服务器可以用自身的网络地址连接服务端，从而隐藏客户端的真实身份。
代理服务器理解客户端要访问的地址后，会向服务端发送请求获取响应，再将响应返回给客户端。
这是 HTTP 代理服务器最简单的实现形式，但存在明显缺陷：代理服务器以明文形式处理客户端流量，可能在转发过程中记录用户流量，存在潜在安全风险。因此，需要考虑加密方式以保障安全性。
HTTPS 流量与代理服务器的复杂工作原理
随着 HTTPS 加密流量在所有 HTTP 流量中的占比不断提升，代理服务器必须适应这一场景。
但问题也随之而来：客户端发送给服务提供商的流量现已加密，代理服务器无法通过解密得知客户端要访问的资源。这是因为客户端与服务提供商之间通过基于非对称加密算法的密钥协商机制保护流量，后续的加密流量使用的对称密钥，通信过程中的中间人无法获取。TLS 协议的核心目的就是防止中间人攻击的发生。
那么，代理服务器在这种情况下如何工作？
相比之前的明文请求解析方式，这一过程更为复杂。HTTP 协议引入了专门的 CONNECT 请求方法，客户端通过该方法向代理服务器发送初始请求：
客户端向代理服务器发送 CONNECT 请求，包含想要连接的域名（或 IP 地址）和端口。代理服务器收到请求后，与目标服务建立 TCP 连接，并存储客户端与服务端之间的端口映射关系。之后，客户端可向代理服务器发送正常请求，代理服务器会原样转发流量至服务端，不会尝试解析数据。因此，HTTPS 的加密通信依然可靠。
与明文 HTTP 代理相比，这种机制适用性更广。一旦第一个 HTTP 请求告知代理服务器建立连接所需的信息，它本质上就变成了一个透明的代理通道，既可以支持 HTTPS 流量，也能让 TCP 二进制流量（如 SSH）通过代理服务器进行通信。
本文转载自 雪兽软件
更多精彩推荐请访问 雪兽软件官网