我们通常选用 NGINX 或 Apache 作为负载均衡器和反向代理服务器，即便外部网络流量通过它们的中转到达内部网络的实际服务。有了反向代理，自然也有普通的代理服务器，我们将在以下内容中详细探讨其作用。
网络协议和分层结构：从 OSI 模型到代理服务器
在访问互联网服务时，我们通常使用 HTTP 协议，其工作在 OSI 模型的第 7 层位置。我们熟悉的 URL，如主机名、路径、请求参数等，都是 HTTP 协议的一部分。HTTP 协议基于 TCP 或 UDP 协议，它们工作在 OSI 模型的第 4 层位置，而我们访问服务时使用的端口/port 概念则在这些协议中。更进一步，TCP 和 UDP 都基于 IP（Internet Protocol）协议，它工作在 OSI 模型的第 3 层位置，IP 地址作为“互联网门牌号”在这里实现。
在使用 IP 网络访问互联网时，IP 协议负责寻址目标地址，按规则封装数据报文，并在 IP 网络中将数据包从来源地址发送到目标地址。例如，网络流量从访问者所在的局域网通过 ISP 提供的网关设备连接到 ISP 的网络，再访问到资源提供者的服务。
此时，我们使用网关来访问互联网。谈到代理服务器时，我们可以将其与 IP 网络进行类比。代理服务器在这时充当网关的角色，以桥梁的方式帮助客户端访问服务。它实际上工作在 OSI 模型的 L4 传输层和 L7 应用层之间，确切地说，它属于 OSI 模型的 L5，即会话层。
代理服务器的用途
我们通常使用代理服务器来实现以下目的：
- 内部网络访问的集中出口
当我们位于企业内部时，通常会有一些信息安全的要求，比如对网络访问的准入和流量的记录，以防止秘密信息泄露。如今随着 HTTPS 之类的加密流量的普及，网络流量被隐藏在密码之下，导致网络边界无法记录和审计这些流量，从而增加了泄密风险。代理服务器的存在可以用作统一流量出口，作为一个中间人来处理流量审计工作。
除了面向人类的用途，代理服务还可以用于程序服务对外访问的出口。例如，当服务商的业务提供 webhook 功能时，它需要让流量通过一个固定的出口流出，使用固定的单一 IP 地址或固定的 IP 地址段，这有利于 webhook 调用的接收方正确地将其列入防火墙的白名单。如果服务商不这样做，webhook 调用的双方都可能面临安全风险。
- 隐匿访问者身份
有时，作为互联网访问者，我们可能希望隐藏自己的身份，例如 IP 地址等。此时，可以使用透明代理服务器。客户端首先连接到代理服务器，告知需要连接的真正服务地址，然后通过代理服务器使用 HTTPS 协议访问目标服务。代理服务器的存在保证了客户端身份的隐藏，内层通信使用的加密协议则保证代理服务器在此过程中无法窃取数据。
基于 HTTP 的代理
在代理服务器上，我们通常会看到基于 HTTP 的 HTTP proxy 和基于二进制协议 SOCKS4/5 协议，以不同的实现方式做相似的事情，接下来我们主要讨论基于 HTTP 的代理。
在协议实施的早期，HTTP 上的流量主要是明文的 HTTP 流量。这对于流量经过的所有环节来说都是透明的。在客户端和服务中间的代理服务器可以轻松地从请求中解析出 URL 和请求负载等。通过 DNS 解析等环节，它可以以自己的网络地址连接到服务，从而将客户端隐藏起来。
我们使用这样的调用方式：
1GET http://example.com/resource HTTP/1.1
2Proxy-Authorization: Basic encoded-credentials
代理服务器了解客户端正在尝试访问的地址，并向服务发送请求以获取响应，然后将其返回给客户端。
1HTTP/1.1 200 OK
2Content-Type: text/html
3
4...
5body blahblah
6...
这是 HTTP 代理服务器中最简单的实现形式，但我们可以发现其中的缺点：代理服务器以明文方式处理客户端流量，可能在转发过程中记录用户流量，造成安全风险。我们必须考虑使用加密方式来确保安全性。
HTTPS 流量和代理服务器
随着 HTTPS 加密流量在全部 HTTP 流量中占比的提高，代理服务器也需要处理这种场景。
然而，我们会发现一个问题：客户端发送给服务提供商的流量现在已经是加密的了，代理服务器无法通过解密方式了解客户端正在访问什么资源。因为流量正在通过客户端和服务提供商之间的基于非对称加密算法等的密钥协商机制保护，后续流量加密使用的对称密钥不可能被通信过程中的中间人获得，而 TLS 的设计根本目的之一就是为了避免中间人攻击的可能性。
那么代理服务器将如何工作呢？
这相较于以前基于明文请求解析的方式更加复杂。HTTP 协议中引入了一个专门的请求方法 CONNECT。客户端使用这种方式发送初始请求到代理服务器：
1CONNECT server.example.com:80 HTTP/1.1
2Host: server.example.com:80
3Proxy-Authorization: Basic encoded-credentials
客户端发送一个 CONNECT 请求到代理服务器，其中包含客户端希望连接的服务域名或 IP 地址以及端口。代理服务器收到请求后建立与目标服务的 TCP 连接，并存储来自客户端与服务的端口映射关系。紧接着客户端就可以向代理服务器发送正确的请求，它将以原样将流量转发给服务，而不会尝试解析其中的数据，因此 HTTPS 的加密通信是可靠的。
这个机制相较于明文的 HTTP 代理更加通用，因为当第一个 HTTP 请求告知代理服务器信息以建立连接时，它实际上变为了一个透明的代理通道，无论是 HTTPS 还是 TCP 二进制流量（比如 SSH），都可以通过代理服务器进行通信。
总结
本文深度剖析了正向代理的概念，围绕 OSI 模型和代理服务器展开讨论，还介绍了基于 HTTP 的代理和处理 HTTPS 流量的复杂性，以及代理服务器通过 CONNECT 请求方法来处理加密通信的机制。